Game control method and electronic device

Abstract

The present disclosure provides a game control method and an electronic device, comprising: in a first game stage, in response to a selection operation on at least one first virtual object, marking a target first virtual object; wherein the at least one first virtual object is a virtual object configured to participate in a battle in the first game stage; in a second game stage, displaying a marked state of the target first virtual object in a virtual scene; and in response to a batch processing operation, performing batch processing on the marked target first virtual object. In this way, by pre-marking in the first game stage and batch processing in the second game stage, the interaction steps of the second game stage are reduced, which helps to reduce the instruction receiving amount and data processing load of the terminal in a short period of time.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to game control methods and electronic devices. Background Technology

[0002] In related technologies, some game applications (such as auto chess games) often require players to frequently adjust their lineups based on the battle situation, which often involves selling or replacing multiple virtual objects. The typical mechanism is as follows: after the battle phase ends, a preparation phase begins, where players drag virtual objects to a designated area or use shortcut keys to select and sell unwanted virtual objects one by one.

[0003] However, the above approach concentrates a large number of operations in the time-limited preparation phase, causing the terminal to need to process a dense stream of interactive commands in a short period of time, increasing the data processing load. At the same time, the high frequency of sequential operations also makes it easy to generate erroneous commands, resulting in wasted system resources. Summary of the Invention

[0004] This application provides a game control 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 application, a game control method is provided, which provides a graphical user interface via a terminal, the graphical user interface including a virtual scene, the method comprising: in a first game phase, in response to a selection operation for at least one first virtual object, marking a target first virtual object; wherein the at least one first virtual object includes a virtual object configured to participate in combat in the first game phase; in a second game phase, displaying the marking status of the target first virtual object in the virtual scene; and in response to a batch processing operation, performing batch processing on the marked target first virtual object.

[0006] According to one aspect of this application, a game control device is provided, which provides a graphical user interface via a terminal. The graphical user interface includes a virtual scene. The device includes: a marking module configured to, in a first game phase, mark a target first virtual object in response to a selection operation for at least one first virtual object; wherein the at least one first virtual object includes a virtual object configured to participate in combat in the first game phase; a display module configured to, in a second game phase, display the marking status of the target first virtual object in the virtual scene; and a processing module configured to, in response to a batch processing operation, perform batch processing on the marked target first virtual object.

[0007] According to one aspect of this application, 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 methods described above.

[0008] According to one aspect of this application, 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 methods described above.

[0009] One embodiment of this application provides a game control method, including: in a first game phase, in response to a selection operation for at least one first virtual object, marking a target first virtual object; wherein the at least one first virtual object is a virtual object configured to participate in combat in the first game phase; in a second game phase, displaying the marked state of the target first virtual object in a virtual scene; and in response to a batch processing operation, performing batch processing on the marked target first virtual object. In this way, by pre-marking virtual objects in the first game phase and performing batch processing in the second game phase, high-frequency interactive operations originally concentrated in a single phase are distributed across different phases and aggregated into batch instructions. This reduces the number of operation steps and interaction frequency in the second game phase, helps avoid instruction redundancy caused by short-term high-frequency operations, reduces the instruction processing pressure on the terminal within a limited time window, and improves the data processing efficiency of the terminal. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, 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 application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This illustration shows a schematic flowchart of a game control method provided in one exemplary embodiment of this application; Figure 2 This illustration shows an application scenario diagram of a game control method provided by one exemplary embodiment of this application; Figure 3 This illustration shows another application scenario of the game control method provided by one exemplary embodiment of this application; Figure 4 This illustration shows another application scenario of the game control method provided by one exemplary embodiment of this application; Figure 5 This invention provides a schematic diagram of the structure of a game control device according to one exemplary embodiment of the present application. Figure 6This illustration shows a schematic diagram of the structure of an electronic device according to one exemplary embodiment of the present application. Detailed Implementation

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

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

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

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

[0016] The aforementioned virtual object refers to a controllable dynamic object within a virtual scene. Optionally, this dynamic object can be a virtual character, virtual animal, anime character, etc. This virtual object is a character controlled by the player through an input device, or an AI character trained and set up for battle in a virtual environment, or an NPC set up for battle in a virtual scene. Optionally, this virtual object is a virtual character competing in a virtual scene. Optionally, the number of virtual objects in the virtual scene battle is preset or dynamically determined based on the number of clients joining the battle; this application embodiment 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 application can 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 runs 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 game control method of this application, a graphical user interface is provided through a terminal, the graphical user interface including a virtual scene, such as... Figure 1 As shown, the method may include: Step S110, in the first game phase, in response to a selection operation for at least one first virtual object, a target first virtual object is marked; wherein, at least one first virtual object includes virtual objects configured to participate in combat during the first game phase; Step S120: In the second game phase, the marked state of the target first virtual object is displayed in the virtual scene; Step S130: In response to the batch processing operation, perform batch processing on the marked target first virtual object.

[0021] According to one embodiment of this application, by pre-marking virtual objects in the first game stage and performing batch processing in the second game stage, the high-frequency interactive operations that were originally concentrated in a single stage are distributed to different stages and aggregated into batch instructions. This reduces the number of operation steps and interaction frequency in the second game stage, helps to avoid instruction redundancy caused by short-term high-frequency operations, reduces the instruction processing pressure on the terminal within a limited time window, and improves the data processing efficiency of the terminal.

[0022] The embodiments of this application will be further described below.

[0023] In an optional implementation, a graphical user interface (GUI) is provided via a terminal, which includes a virtual scene. This provides an intuitive visual presentation and interactive basis for subsequent game phase switching, virtual object marking, and batch processing, facilitating cross-phase operations for players within a unified interface. In one implementation, the terminal can be a mobile device such as a smartphone or tablet, or a personal computer. For example, a player launches an auto chess game application via a smartphone, which renders and displays a GUI containing a chessboard area on the phone screen. This chessboard area is further divided into a battle area and a preparation area for placing and displaying multiple virtual objects. Players can interact with elements in the virtual scene using input devices such as a touchscreen or mouse.

[0024] Optionally, the virtual scene can be the chessboard environment of an auto chess game. This chessboard environment includes not only a battle area for combat, but also a preparation area for placing candidate objects and a sales area for triggering the sales function. Considering that players need to focus on different information at different game stages, as a possible implementation, the content displayed in the virtual scene can be dynamically switched according to the current game stage. For example, in the battle stage, the virtual scene can focus on displaying the dynamic combat performance and skill release effects of virtual objects; while in the preparation stage, the virtual scene can highlight the positioning grid on the chessboard, the operable control panel, and the attribute information of each virtual object. It should be noted that the above-mentioned area division of the virtual scene is only one example, and this application is not intended to limit the composition of the virtual scene. In actual implementation, the virtual scene can also include a shop area, an equipment area, or other auxiliary interactive areas. These areas can be laid out around the core chessboard area to support players in completing diverse operations such as object purchase and equipment synthesis, thereby providing a complete spatial basis for cross-stage object marking and batch processing.

[0025] In step S110, during the first game phase, in response to a selection operation targeting at least one first virtual object, the target first virtual object is marked; wherein, at least one first virtual object is a virtual object configured to participate in the battle during the first game phase. By marking the first virtual objects participating in the battle in response to a selection operation during the first game phase, players can plan their formation strategies in advance, bringing forward the complex selection operations of subsequent phases, effectively alleviating time pressure and reducing the error rate in later phases. In one embodiment, when watching the battle animation during the battle phase of a target round, a player finds that their current lineup is insufficient to cope with the enemy's output and decides to change some of their front-line characters in the next round. At this time, the player clicks the marking control displayed on the interface to bring up a semi-transparent marking interface, which displays multiple virtual characters currently in the battle area. By continuously clicking on three of the front-line virtual characters, a checkmark appears above the selected characters, thus completing the pre-marking of these three target first virtual objects.

[0026] Optionally, the first game phase refers to the time window during a game when players are allowed to perform pre-marking operations. This can be a phase where the two sides automatically engage in combat. Alternatively, the first game phase can be the combat phase in an auto-chess game, where virtual objects from both sides automatically attack and unleash skills. Considering that players need to perform multiple operations simultaneously during the preparation phase, such as purchasing, repositioning, and selling, making time extremely tight, moving the marking operation to the combat phase can make full use of the idle time players have while spectating. It should be noted that the first game phase can also be other non-preparation phase periods, such as the round settlement phase or a specific spectating phase, as long as the player can access the marking interface during that phase. This application does not impose any restrictions on this, thus providing players with more flexible options for when to perform their actions.

[0027] Optionally, the first virtual object can be a combat unit such as a chess piece or hero character in an auto chess game. These virtual objects are configured in the battle area at the start of the first game phase to participate in automatic combat. It should be noted that the specific form and number of the first virtual objects can change dynamically according to the game progress. For example, temporary combat units summoned by the player through specific skills during combat can also be classified as first virtual objects, thus ensuring the comprehensiveness of the marking scope.

[0028] Optionally, the way the first virtual object is presented in the marking interface can be mapped to its initial position in the battle area. In other words, the marking interface doesn't simply list the characters, but rather recreates their initial formation positions at the start of the round in the form of thumbnails or models. This spatial mapping design helps players intuitively recall the tactical roles of each character and avoids misselection due to discrepancies between the list arrangement and the actual positions. If a character's position moves during the battle, the marking interface retains its initial position, serving as a reference for players to plan subsequent formation changes.

[0029] Optionally, the selection operation is used to determine the target first virtual objects that need to be batch processed from at least one first virtual object, which can be achieved through various interactive gestures. Optionally, the selection operation can be a click operation, a continuous swipe operation, or a long press operation on virtual objects in the marking interface. Considering that players may need to mark multiple virtual objects at once, using a swipe operation can significantly improve selection efficiency. For example, if a player's finger traces a path on the marking interface, the system automatically identifies all virtual objects that the path passes through as target first virtual objects. It should be noted that for a target first virtual object that has already been selected, its selection state can be deselected when a selection operation is received again, thus providing a convenient error correction mechanism to avoid marking errors caused by accidental touches.

[0030] Optionally, in addition to the aforementioned touch gestures, selection operations can also include input commands based on key combinations. In PC applications, players can complete selections by combining keyboard keys and mouse clicks; for example, holding down a specific key while clicking multiple virtual objects to select multiple targets. To prevent accidental selection of unwanted key characters during rapid swiping, the system can highlight all selected objects after selection and require the player to confirm again, or automatically confirm if no action is taken within a specific timeframe. This serves as a foolproof mechanism to ensure the accuracy of the player's strategy.

[0031] In an optional implementation, the first game phase is the combat phase of the target round, and the second game phase is the preparation phase for the next round of the target round. By clearly defining the first game phase as the combat phase and the second game phase as the preparation phase, players can utilize the spectator time during the combat phase to pre-plan and mark objects to be processed, and then quickly execute batch processing during the time-constrained preparation phase, effectively avoiding the problem of untimely operations during the preparation phase.

[0032] In one implementation, taking an auto chess game as an example, the first game phase can be the battle phase of the target round. At this time, the virtual objects of both sides are automatically fighting in the virtual scene. Players do not need to perform real-time operation intervention. They can use this time to open the marking interface and pre-select and mark multiple pieces (i.e., virtual objects) currently in the game. When the battle phase of the target round ends and the preparation phase of the next round (i.e., the second game phase) begins, players can directly perform a batch sale operation on the previously marked pieces without having to search and select them one by one within the limited countdown of the preparation phase.

[0033] Optionally, the battle phase is the stage in which virtual objects automatically execute combat logic during a game turn. During this period, players can spectate and perform non-combat strategy planning operations.

[0034] Optionally, the battle phase can be a stage in auto chess where virtual objects from both sides automatically attack and unleash skills. Considering that players don't need real-time movement or skill activation during this phase, and their focus is primarily on observing the battle situation, the aforementioned method allows the marking interface to be opened at this time. This enables players to make full use of fragmented spectating time to predict potential changes. It should be noted that the battle phase includes not only the actual combat period but also a short preparation transition period before the battle concludes. During this phase, the virtual objects presented in the graphical user interface are usually in a dynamic combat state, but the marking interface can display them with static initial positions, thus avoiding interference from dynamic effects on the player's marking selection and improving the accuracy of information acquisition in complex battle scenarios.

[0035] Optionally, the triggering and duration of the battle phase can be dynamically configured according to the game's rules. To avoid the marking operation affecting the player's observation of the battle result, the marking interface can be displayed as a semi-transparent panel overlaid on the battle screen without obscuring the core battle area. In addition to keeping the marking function open throughout the entire battle phase, the marking control can also be activated only in specific sub-periods of the battle phase (such as the later stages when the battle result is already determined), to prevent players from marking too early and ignoring changes in the battle situation. One objective of this embodiment is that by bringing the marking timing forward to the battle phase, on the one hand, it can distribute the operational pressure of the preparation phase, and on the other hand, it allows players to more accurately decide what to sell based on real-time battle performance, thereby improving the rationality and timeliness of strategy adjustments.

[0036] Optionally, the preparation phase is the interval between two adjacent battle phases, used for players to perform lineup management operations such as adjusting the deployment of virtual objects, purchasing or selling them. Optionally, the preparation phase can be a countdown phase in auto chess gameplay that gives players a fixed duration (e.g., 30 seconds) for lineup adjustments. Considering that players need to perform multiple intensive operations during this phase, such as purchasing new objects, adjusting positions, synthesizing and upgrading stars, and selling old objects, time is extremely tight. The above method directly presents pre-marked objects in a batch-processable state during this phase, significantly reducing the time required for individual selection and processing. During this phase, the graphical user interface usually displays a preparation area and a battle area. The marked target virtual object can be distinguished from other objects by specific visual effects (e.g., a red glowing outline). If the player does not perform batch processing before the preparation phase countdown ends, the system can automatically remove the marking state or retain the marking state for use in the next round; this application does not limit this.

[0037] Optionally, the preparation phase, besides serving as a time for bulk sales, can also act as a window for confirming and correcting the marked status. To avoid incorrect marking due to observation errors during the battle phase, the above method can flexibly cancel the marking status when a specific operation (such as long-pressing or dragging to the cancellation area) is detected on the marked object during the preparation phase. It should be understood that the length of the preparation phase may vary depending on the game mode; for example, in quick mode, the preparation phase may only last 15 seconds. In this case, the advantages of cross-phase pre-marking and one-click batch processing mechanisms are even more significant, effectively preventing players from being unable to complete lineup changes due to insufficient hand speed, thereby ensuring the smoothness of the game and the player's operating experience.

[0038] In an optional implementation, in response to a selection operation on at least one first virtual object, marking the target first virtual object includes: displaying a marking interface showing at least one first virtual object; and marking the target first virtual object in response to a selection operation on at least one first virtual object displayed in the marking interface. Thus, by providing a separate marking interface, players can intuitively pre-mark virtual objects without interfering with the current game progress, thereby improving the accuracy and convenience of the marking operation and laying the foundation for subsequent batch processing.

[0039] In one implementation, players can bring up a marker interface by clicking a marker control that appears in the graphical user interface during the first game phase (e.g., the battle phase). This marker interface floats above the game screen and displays the various virtual objects currently participating in the battle. Players can quickly select virtual objects that need to be processed in batches (e.g., sold) by clicking or swiping. Selected objects will display a corresponding checkmark for batch processing in subsequent phases.

[0040] Optionally, the marking interface receives selection operations for the first virtual object, and its presentation at least partially includes the visual identifier of the first virtual object for players to pre-mark. Optionally, the marking interface can be displayed on the graphical user interface as a floating window, sidebar, or bottom panel. Considering that players still need to observe the battle situation during the combat phase, the marking interface can adopt a semi-transparent display style, thus providing an operation entry point without obstructing the combat screen. It should be noted that the at least one first virtual object displayed in the marking interface may only include virtual objects currently engaged in combat in the combat area, excluding virtual objects in the preparation area. This is because virtual objects in the preparation area can usually be directly sold during the combat phase without additional marking. This differentiated display effectively reduces redundant information in the interface, lowers the visual search cost for players, and allows the marking operation to focus more on virtual objects that truly require cross-phase processing.

[0041] Optionally, to facilitate smoother cross-stage marker management, the marker interface can automatically pop up at a specific time during the first game stage (such as the battle stage), or it can be passively invoked in response to a player's touch operation on a designated control. One objective of this embodiment is to distribute tedious operations that would otherwise need to be completed centrally during the preparation stage to the battle stage by providing a marker interface during the battle stage. This alleviates the time pressure during the preparation stage and allows players ample time to strategize changes. Furthermore, if the system detects that a player has triggered other high-priority game operations while the marker interface is displayed, it can temporarily hide or weaken the marker interface to avoid accidental touches. After the player completes the marker operation, they can collapse the marker interface by clicking the close button or a blank area outside the interface. The system will automatically save the current marker state for inheritance and display in the next game stage.

[0042] like Figure 2 As shown in an exemplary application of this embodiment, during the battle phase of an auto chess game, a player triggers a marking control 200 to open a semi-transparent marking panel 201. The marking panel 201 displays multiple first virtual objects currently participating in the battle in a grid format. The player selects three target first virtual objects that they wish to sell in bulk during the next preparation phase by clicking. The terminal responds to this selection by marking these three target first virtual objects, displaying a checkmark on the grid corresponding to each marked target first virtual object. This allows the player to perform unified processing on these marked target first virtual objects through batch processing in subsequent phases.

[0043] In an optional implementation, the position of at least one first virtual object displayed in the marking interface is mapped to the initial position of at least one first virtual object in the combat area of ​​the virtual scene at the start of the first game phase. This allows players to intuitively match their starting position in the marking interface, reducing the cognitive load when marking across phases, avoiding marking misalignment caused by dynamic combat effects, and improving operational accuracy.

[0044] In one implementation, during the target round's battle phase, the player clicks a marker control at the bottom of the graphical user interface, which then pops up a semi-transparent marker interface at the bottom of the screen. This marker interface displays all currently deployed pieces, and their arrangement is identical to their positions on the board at the start of the current round. For example, a piece located in the middle of the first row of the board is also displayed in the middle of the first row in the marker interface. The player can pre-mark the corresponding piece by clicking or swiping, eliminating the need to search for the target in the dynamic battle screen.

[0045] Optionally, the mapping can include coordinate correspondence or scaling relationships, used to transform the spatial distribution of virtual objects in a three-dimensional or two-dimensional scene to a two-dimensional marker interface for display. The mapping can be a coordinate correspondence achieved through a spatial coordinate transformation algorithm, or a scaling mapping according to a preset ratio. Considering that virtual objects will dynamically shift based on skill releases or movement commands during the battle phase, directly obtaining the dynamic position of the current frame for mapping would cause frequent jumps in the object positions on the marker interface, affecting the player's selection operations. Therefore, as a possible implementation, the system captures and freezes the spatial coordinates of all first virtual objects participating in the battle in the battle area at the moment the first game phase begins, and uses this set of static coordinates as the mapping source data. When generating the marker interface, the system calculates the relative display coordinates of each first virtual object in the marker interface based on this set of static coordinates and the size parameters of the marker interface, thereby ensuring that the layout in the marker interface is highly consistent with the initial battle formation. It should be noted that the above mapping can be applied not only to hexagonal grid chessboard scenes, but also to square grid or gridless free-position scenes; this application does not limit this application.

[0046] Optionally, the initial position may include the grid coordinates or orientation information relative to a reference point assigned to the virtual object by the system at the start of the round.

[0047] The initial position can be the grid coordinates assigned to each first virtual object by the system at the start of the first game phase (i.e., the combat phase of the target round) before the combat logic officially runs. To avoid inaccurate position data due to network latency or client frame rate fluctuations, the system can record a snapshot of the coordinates of all deployed virtual objects at the same time the server issues the round start command. Furthermore, if a first virtual object's position is temporarily adjusted by the player before the round starts, the system will record the final confirmed position as its initial position. In this way, regardless of any complex displacements and collisions that occur during combat, the marking interface always uses this determined initial position as the display reference, providing players with a stable and predictable marking view, effectively reducing the visual search cost when performing cross-phase operations.

[0048] In step S120, during the second game phase, the marked state of the target first virtual object is displayed in the virtual scene. This allows players to quickly identify pre-marked objects by visually displaying their marked state during the second game phase, preventing forgetting or misoperation, thereby improving the accuracy and consistency of cross-phase batch processing.

[0049] In one implementation, when the game transitions from the battle phase to the preparation phase, previously selected pieces (i.e., the target first virtual objects) in the graphical user interface are automatically marked with special visual identifiers. For example, these marked pieces may be surrounded by a red glowing outline, or an icon with a checkmark may float above their heads, clearly informing the player that these characters are in a queue awaiting batch processing, helping the player quickly locate and execute subsequent actions within the limited preparation time.

[0050] Optionally, the marking status indicates that the first target virtual object has been selected and is awaiting batch processing, and its presentation can take various visual forms. Optionally, the visual representation of the marking status can include, but is not limited to, color changes, special effects halos, additional icons, or combinations thereof. Considering that players need to quickly locate and distinguish marked objects during the preparation phase, as a possible implementation, the above marking status can be achieved by changing the display style of the first target virtual object, for example, rendering the edges of the first target virtual object's model with a red glowing outline, or generating a magic circle effect of a specific color below its model. It should be noted that the above description of visual representation is only one example and is not intended to limit the specific composition of the marking status. In actual implementation, the status can also be represented by displaying a specific status label (such as a badge with the words "For Sale") floating above the first target virtual object, as long as the marked object is visually clearly distinguishable from other unmarked objects, thereby ensuring that players can accurately capture key information even in complex combat scenarios.

[0051] Optionally, in addition to representing the marking state through static visual identifiers, the marking state can also include dynamic indicative information or guiding effects. To prevent players from having difficulty finding the marked object due to changes in interface elements after entering the second game stage, the above method can also generate dynamic guide lines or flying effects pointing from specific UI controls (such as marking panel buttons) to the target first virtual object when displaying the marking state. One objective of this embodiment is that, through such dynamic visual guidance, the visual impact of the marking state can be further enhanced, and the player's gaze can be quickly focused on the target location, reducing visual search costs. Furthermore, if the quality of the target first virtual object changes or is processed separately in the second game stage, the marking state will also be dynamically updated or canceled accordingly to ensure that the interface display information remains highly consistent with the actual set of objects to be processed, preventing misoperations caused by state lag.

[0052] In an optional implementation, displaying the marked state of the first target virtual object in the virtual scene includes: displaying target effects in the graphical user interface to represent the marked state of the first target virtual object; wherein the target effects include at least one of the following: the first target virtual object is displayed in a display style different from other first virtual objects in the combat area of ​​the virtual scene; and an indicator pointing from the marking control to the first target virtual object. In this way, displaying the marked state through intuitive visual effects not only helps players quickly identify the virtual objects to be processed in the second stage of the game, but also avoids visual obstruction caused by text prompts, improving the efficiency of information acquisition and the accuracy of operation.

[0053] In one implementation, when the game switches from the battle phase to the preparation phase, the graphical user interface automatically displays target effects to represent the marked status. For example, multiple pieces pre-marked by the player will display glowing red outlines, while several semi-transparent guide rays will be emitted from the marking controls at the bottom of the interface, flying towards and attaching to these marked pieces. This multi-dimensional visual feedback allows players to instantly locate all virtual objects to be processed in batches without having to check the attributes of each piece individually, greatly reducing visual search costs.

[0054] Optionally, the presentation of the target effect can be diverse, at least partially including visual content to distinguish the first virtual object being marked. Optionally, the target effect can be a glowing effect, an animated cue, or a combination thereof. Considering that players need to quickly shift their attention from the battle outcome to lineup adjustments during the transition from the battle phase to the preparation phase, the aforementioned target effect can be directly displayed in the graphical user interface without requiring additional player triggering. For example, the target effect could be a red halo surrounding the marked piece, or a particle flow effect flying from the marking control towards the marked piece. It should be noted that the above description of the specific presentation of the target effect is only one example, and this application is not intended to limit the visual composition of the effect. In actual implementation, it can be determined according to the overall art style of the game or the player's personalized settings, as long as a significant visual distinction can be achieved.

[0055] Optionally, the marker control is used to receive trigger actions to display the marking interface, and it can serve as the starting point for emitting indicators pointing to the marked objects. Optionally, the marker control can be placed in the bottom edge area of ​​the graphical user interface, or in the sidebar or other non-core view areas. Considering that players need to frequently drag pieces between the combat area and the preparation area during the preparation phase, placing the marker control at the bottom can minimize obstruction of the operation hotspot. In one specific way, the marker control appears as a semi-transparent circular button; clicking the button expands or collapses the marking interface. Furthermore, when displaying target effects, the marker control can serve as the starting point for animation prompts, i.e., light or particle effects originate from the position of the control and fly towards each marked piece. It should be noted that the shape and position of the marker control are not limited to the above examples; they can adaptively adjust according to the screen size and interface layout of the terminal device.

[0056] Optionally, in addition to serving as the starting point for animations and the entry point for the interface, the marker control can also function as a status indicator. To prevent players from accidentally expanding the blank interface when no pieces are marked, the marker control can display a badge indicating the number of marked objects. If all marked objects are unmarked, the marker control can automatically switch to a dormant mode, such as reducing transparency or stopping the breathing light effect. Similarly, players can drag the piece to the marker control to unmark it, at which point the marker control also functions as a recycle bin. This design makes the marker control not only a carrier of information but also a hub for the interaction flow, improving the fault tolerance and convenience of operation.

[0057] Optionally, the indicator is used to establish a visual association between the marker control and the target first virtual object, so as to guide the player's eye to locate the marked object.

[0058] Optionally, the indicator can take the form of a light, arrow, dotted line, or guide trajectory. Considering that the first virtual object being marked may be distributed in various locations within the combat area, and some objects may be obscured by other objects or interface elements, the display of the indicator can employ dynamic tracking logic. Specifically, the indicator originates from the marking control, and its end dynamically adjusts its pointing angle according to the position change of the marked object. In one implementation, the indicator is displayed as a Bézier curve with a flowing light effect, which not only clearly outlines the spatial relationship between the starting and ending points, but its flowing particles can also further attract the player's visual focus.

[0059] Optionally, the display style is used to characterize the visual differentiation of the target first virtual object from other first virtual objects. Optionally, the display style may include at least one of color variation, transparency adjustment, scaling differences, or additional decorative elements. To avoid difficulty for players in quickly identifying marked individuals in a dense array of pieces, the marked target first virtual object may adopt a color tone distinctly different from unmarked objects. For example, unmarked pieces maintain normal color saturation, while marked pieces are given a high-contrast outline or an overall tone shift. One objective of this embodiment is to make the marked object appear "protruding" visually through the adjustment of the display style, thereby effectively reducing the visual search cost for players in complex scenes and improving positioning efficiency.

[0060] like Figure 3 As shown in an exemplary application of this embodiment, after the auto chess game ends and enters the preparation stage, a marker control 200 is displayed at the bottom of the graphical user interface. At the same time, indicator rays 300 are emitted from the marker control 200 to the three previously marked target first virtual objects. Players can intuitively identify the set of virtual objects to be processed in batches through the above visual effects, without having to search for them one by one among multiple virtual objects.

[0061] In an optional implementation, the method further includes: in the second game phase, if the quality of the second virtual object within the marked target first virtual object meets a preset change condition, then the marking status of the second virtual object is canceled. This avoids mistakenly selling high-value objects due to an improvement in the quality of the marked object, thus improving the security of batch processing and the rationality of resource management.

[0062] In one implementation, when a player views the marked pieces during the preparation phase, they may find that a piece has been upgraded due to the purchase of a new identical piece. At this point, the piece's star rating increases from one to two stars. The system detects this change in quality and confirms that it meets preset conditions. It then automatically removes the marked status of the upgraded piece, removing it from the batch sale set. This prevents the player from mistakenly selling the high-star piece during subsequent batch sales.

[0063] Optionally, the second virtual object can refer to a specific virtual object whose quality attributes dynamically change among at least one marked target first virtual object. Optionally, the second virtual object can be any one or more of the initially marked virtual objects. It should be noted that the above description of the second virtual object is merely an example, and this application is not intended to limit the composition of this feature. In actual implementation, it can be determined based on experience or specific application conditions. Considering that the attributes of virtual objects are not static during the game, as a possible implementation, the aforementioned second virtual object can specifically be a virtual object whose basic or additional attributes change before or during the second game phase. To avoid misjudgments or resource losses in subsequent batch processing due to attribute changes, the above method, when detecting a member in the marked set with attribute changes, independently identifies it as a second virtual object for subsequent state update logic. It should be understood that the second virtual object can differ visually from other unmarked first virtual objects, for example, through different border colors or highlighting effects, thus making it easier for players to intuitively identify which objects have undergone quality changes.

[0064] Optionally, quality is used to characterize the overall ability rating of a virtual object in a game, and may include at least one of star rating, level, rarity, or enhancement stage. Optionally, quality is not only related to the basic attributes of a single virtual object, but also to the combination of multiple virtual objects or the bonuses from equipment and items. Based on this, the process of determining the quality mentioned above may specifically include: determining the basic rating based on the basic panel values ​​of the virtual object, determining the bonus coefficient based on the additional attributes of equipment or the combination of synergies, and calculating the final quality parameter based on the basic rating and the bonus coefficient. It should be noted that the above representation of quality is only one example, and this application is not intended to limit the composition of this feature. In actual implementation, it can be determined based on experience or specific application. In one specific way, quality can be represented by a star rating from one to three stars, with the higher the star rating, the stronger the combat ability of the virtual object; in another way, quality can also be represented by rarity tags such as common, rare, and epic. Different quality indicators can be loaded and displayed at different stages of operation, and their display parameters can be dynamically switched according to the status, allowing players to intuitively obtain the current object's strength information.

[0065] Optionally, preset change conditions are used to determine whether the magnitude or direction of quality change of a virtual object reaches a trigger threshold, and they are dynamically configured according to game strategy requirements. Optionally, preset change conditions can be in the form of quality improvement reaching a specified level, quality downgrading, or quality value change exceeding a preset threshold. It should be noted that the above description of preset change conditions is only one example, and this application is not intended to limit the composition of this feature. In actual implementation, it can be determined based on experience or specific application conditions. Considering that players want to retain high-value objects when selling in bulk, as a possible implementation method, the above preset change conditions may include: the star rating of the virtual object is improved from a low star rating to a high star rating (e.g., from one star to two stars). To avoid players mistakenly selling enhanced objects due to automatic system synthesis, the above method cancels the marking process according to preset rules when the quality improvement meets the condition, or cancels the marking process after obtaining user confirmation. If the quality improvement does not reach the specified level, it is considered that the preset change conditions are not met, and further verification can be carried out using other judgment logic. This application embodiment does not limit this. Similarly, in addition to judging by star rating, other quality parameter changes automatically assigned by the system can also be used as conditions, but this application is not limited to this.

[0066] Optionally, in addition to judging quality improvement, the preset change conditions can also include other judgment logic, such as judging quality decline or quality fluctuation range. This judgment logic can further cover more abnormal scenarios. One objective of this embodiment is to achieve refined marking management by setting multi-dimensional change conditions. On the one hand, this can reduce the risk of losing high-value resources due to player misoperation; on the other hand, it can increase the flexibility and fault tolerance of the batch processing mechanism. In one implementation, if the marked virtual object experiences a quality decline in the second game stage due to a specific event (e.g., equipment being removed or a bond breaking leading to a lower overall rating), although the quality has declined, it may still meet the player's original intention to sell it. Therefore, the system can not cancel the marking but instead prompt the player for confirmation through a pop-up window. It should be understood that different judgment priorities can be loaded at different game stages, and the judgment parameters can be dynamically switched according to the game situation, thereby ensuring the accuracy and security of batch selling operations.

[0067] In an optional implementation, the method further includes: in the second stage, in response to a target operation on a third virtual object within the marked target first virtual object, canceling the marking state of the third virtual object. This provides a flexible target operation cancellation mechanism, giving players the freedom to dynamically adjust the marking state in the second game stage, effectively avoiding the risk of accidental selling due to mismarking in the early stages or temporary tactical changes, and significantly improving the fault tolerance and operational experience of batch processing. In one implementation, after entering the preparation stage, if a player finds that a marked piece no longer needs to be sold due to tactical adjustments, they can directly perform a target operation on that piece. For example, if the player presses and holds the piece model for about 1 second, the system detects the long press gesture, and the red glowing effect on the piece disappears, indicating that the marking state of the piece has been successfully canceled; or, the player can drag the piece to the marking control at the bottom of the interface and release it, which will also trigger the cancellation logic, removing the piece from the set to be batch processed (e.g., sold).

[0068] The third virtual object is any one of the first virtual objects that is being marked.

[0069] Optionally, the target operation is used to trigger the cancellation of the marked state, and it can include various types of touch gestures or button commands applied to the third virtual object. Optionally, the specific form of the target operation can include, but is not limited to, long-press gestures, drag gestures, or click operations. Considering that players may need to quickly and accurately cancel the marked state of a specific virtual object in the second game phase, as a possible implementation, the above-mentioned target operation can be set as a long-press touch on the virtual object itself. When the system detects that the touch duration reaches a preset time threshold (e.g., 800 milliseconds), it is determined to be a valid cancellation command. It should be noted that the above description of the type of target operation is only one example, and this application is not intended to limit the composition of this feature. In actual implementation, the target operation can also be set to other forms according to the hardware characteristics or interface layout of the terminal device, such as through a specified function key on an external keyboard combined with mouse clicks, thereby meeting the needs of players with different operating habits and improving the inclusivity of the interaction.

[0070] Optionally, besides touch operations directly affecting the third virtual object itself, the target operation can also be a complex interactive action achieved by moving the third virtual object to a designated area. To avoid accidental touches or inefficiency due to cumbersome operations during the limited preparation time, the above method can determine the endpoint position of the drag trajectory when it detects the drag trajectory of the third virtual object. If the endpoint position is within a preset marked control area, it is considered to meet the cancellation condition, thereby removing the marked state of the third virtual object. It should be understood that in complex battle interfaces, the target operation can also be dragging a marked control or a dedicated cancellation control to the third virtual object. This application embodiment does not limit this, thereby constructing a multi-dimensional error prevention and fault tolerance mechanism.

[0071] In step S130, in response to the batch processing operation, batch processing is performed on the marked target first virtual object. In this way, all marked virtual objects can be processed at the same time through a single batch processing operation, avoiding the tedious steps of operating one by one, greatly improving the operation efficiency within a limited time, and helping players quickly complete their formation change plan.

[0072] In one implementation, once the game enters the preparation phase, marked pieces are visually distinguished by a red glow, and an animated prompt appears at the entry button on the marking panel, indicating that the pieces are flying towards the marked pieces. Players can perform a three-finger press anywhere on the screen. Upon detecting the three-finger gesture, the system blocks other click operations in that state and simultaneously grabs all marked pieces (i.e., all marked pieces are selected). At this point, the marked pieces can be grouped together and moved following a drag gesture. Players drag the grouped pieces to the selling area and release the button; the system automatically calculates the total price of all marked pieces and completes a one-click bulk sale. On a PC, players can trigger the same bulk grabbing and selling process using the Shift key and mouse drag combination.

[0073] Optionally, batch processing operations are used to trigger unified processing of the marked target virtual objects. These operations can include multi-finger touch operations, key combinations, or long-press drag operations. On mobile terminals, batch processing can manifest as a three-finger simultaneous press and hold gesture on any part of the screen. Upon detecting the three-finger touch, the system blocks other click operations under this gesture state to prevent accidental touches. On PCs and other terminals with physical keyboards, batch processing can manifest as a key combination of the Shift key and mouse drag. The player holds down the Shift key while dragging the marked virtual objects to trigger batch grabbing. It should be noted that the multi-finger touch and key combinations described above are merely examples and are not intended to limit the specific form of batch processing operations. In actual implementation, other trigger operations can be configured according to the terminal type and user habits, such as four-finger touch, Ctrl key plus mouse click, etc., as long as the effect of selecting all marked virtual objects simultaneously in one operation is achieved.

[0074] Optionally, in addition to multi-finger touch and key combination operations, batch processing can also be manifested as a long press and drag operation of one of the virtual objects to be processed (i.e., a target virtual object). For example, dragging a marked target virtual object will cause other marked target virtual objects to move together, or other marked target virtual objects will aggregate with the dragged target virtual object and move together. Considering that players' operating habits may differ in different scenarios, as an alternative, the system can detect the player's long press operation on any marked virtual object. When the long press duration reaches a preset threshold (e.g., 0.5 seconds or 1 second), the long press operation is identified as a batch processing trigger signal, and then all marked virtual objects are controlled to enter the selected state and move with the drag gesture. Furthermore, to avoid players accidentally triggering batch processing due to unintentional long presses in daily operation, the system can display a progress bar or visual feedback during the long press. The batch processing operation is only officially triggered when the progress bar is full, thus providing a certain degree of error tolerance. It should be understood that the above-mentioned preset threshold can be dynamically adjusted according to device performance and sensitivity, and this application does not limit it.

[0075] Optionally, batch processing can include actions such as batch selling, batch transferring, or batch dismantling, which are dynamically determined based on the attributes of the marked virtual objects and user intent. Optionally, batch processing can specifically manifest as a batch selling operation. When performing a batch sale, the system can aggregate all marked virtual objects together, allowing them to move following the player's drag gesture. When the player drags the aggregated virtual objects to the selling area and releases their grip, the system automatically calculates the total price of all marked virtual objects and completes the sale in one go. The aggregation display can be achieved by overlaying multiple virtual objects into a single icon with a quantity indicator, or by closely arranging multiple virtual objects to move with the gesture. One objective of this embodiment is that, through aggregation display and one-click selling, the frequency of player operations within a limited preparation time can be reduced, and the total price calculation can help players quickly assess the selling revenue. Furthermore, if there are other virtual objects in the preparation area that are the same as the marked target virtual object but of lower or the same quality, the system can automatically mark these virtual objects as objects to be processed, thus processing them together during batch processing. Similarly, if a player changes their mind before performing batch processing, they can cancel the marking status by long-pressing the marked virtual object or dragging it to the marking control, or by clicking the pending sale icon displayed in the sales area, thus providing players with a flexible undo mechanism.

[0076] In an optional implementation, in response to a batch processing operation, batch processing is performed on the marked target first virtual object, including: in response to a batch trigger operation, controlling the marked target first virtual object to be in a selected state; and in response to a batch processing operation on the selected target first virtual object, performing batch processing on the marked target first virtual object. Thus, by splitting batch processing into two stages—batch triggering and execution—not only is the probability of erroneous operations reduced, but also one-click capture and centralized processing of multiple objects is achieved, significantly improving the efficiency and smoothness of batch interactions within the game.

[0077] In one implementation, after the player enters the preparation phase of the next round, marked pieces with special effects are displayed on the screen. The player performs a batch trigger operation, and the system responds by instantly grabbing all marked pieces and aggregating them for display, making them selected. The player then drags this aggregated set of pieces to the selling area at the bottom of the screen. The system automatically calculates the total price of these pieces and completes a one-click sale when the player releases their grip, thus efficiently executing the tactical change plan.

[0078] Optionally, batch triggering operations are used to control the marked virtual objects to uniformly enter the waiting state, and the triggering method can be flexibly configured according to the input modality of the terminal device.

[0079] Optionally, batch triggering operations can be multi-finger touch gestures or key combination inputs. Considering the touch characteristics of mobile screens, as a possible implementation, the above-mentioned batch triggering operations can include pressing and holding any position on the screen with three fingers. When the system detects a three-finger touch signal, other regular click operations in this state need to be blocked to prevent accidental touches. On platforms with physical input devices, such as personal computers, batch triggering operations can be mapped to a combination of keyboard modifier keys and mouse actions, such as long-pressing a specified modifier key and performing mouse drag. It should be noted that the specific forms of triggering operations described above are only examples and are not intended to limit the input modifier. In actual implementation, other input methods that can simultaneously select multiple discrete marked objects can be configured according to the terminal type and user habits.

[0080] Optionally, in addition to triggering via multi-finger gestures or key combinations, batch triggering can also be a preset touch operation targeting a specific single object. To avoid creating an operational barrier for some players due to multi-finger operations, the above method considers a batch trigger operation received when a long press operation is detected on any of the marked target virtual objects. In other words, the player only needs to long press on one of the marked pieces, and the system will automatically recognize the intention and grab all marked pieces at once (i.e., set them to the selected state at once). This design logic not only reduces operational complexity but also provides a more intuitive single-point trigger multi-selection interaction path, allowing players with different operating habits to adapt quickly.

[0081] Optionally, during the detection of batch trigger operations, a foolproof mechanism and fault tolerance judgment can be introduced. Considering that players may unintentionally touch the edge of the screen during intense gameplay, after recognizing multi-finger touch signals, the system can further determine whether the duration of the touch point reaches a preset threshold. If the duration is insufficient, it is judged as an invalid operation and the original interface state is maintained; if the duration meets the condition, the marked object is officially controlled to enter the selected state. Furthermore, after entering the selected state, if the system detects that all touch points have left the screen without effective displacement, it can automatically cancel the selected state and restore the marked standby state. Through this dual timing verification, unexpected batch processing caused by hand tremors or accidental touches is effectively avoided.

[0082] Optionally, the selected state indicates that the virtual object has entered a pending execution mode that can be uniformly processed, accompanied by specific visual effects and position aggregation effects. Optionally, the first virtual object in the selected state can be visually aggregated and move along the movement trajectory triggered by the operation. Considering that multiple discretely distributed virtual objects are difficult to manage during dragging, as a possible implementation, when a marked piece enters the selected state, the system can generate an aggregation carrier near the touch point, storing all selected pieces in the carrier in a scaled-down, stacked, or list format. This aggregation carrier not only simplifies the complexity of interface elements but also allows subsequent dragging operations to be performed on a single carrier. It should be noted that the specific style of the aggregation display can be dynamically adjusted according to the number of objects, and this application does not limit this.

[0083] Optionally, the visual representation of the selected state can also include interface elements such as highlighted outlines, color changes, or hovering tooltips. Before the batch trigger operation is executed, the marked pieces may only have basic marking effects. After the batch trigger operation takes effect, the display style of these pieces can be further switched, such as adding a gold outline or slightly raising their models to clearly distinguish them from other unmarked or unselected objects. The display parameters of the selected state can be dynamically switched at different stages of the operation, such as displaying a semi-transparent effect during dragging and a highlighted preview effect when hovering over the processing area, thereby providing players with clear operational feedback.

[0084] Optionally, batch processing operations are used to execute the final business logic on the selected set of virtual objects, including steps such as region determination and resource settlement.

[0085] Optionally, batch processing can be an operation of dragging a selected target virtual object to a designated functional area. Considering that scenarios such as in-game sales require precise resource settlement, the aforementioned batch processing operation can specifically include: detecting whether the set of selected target virtual objects has been dragged into the judgment range of the sales area; if so, triggering a batch sales command when the player releases their finger. The system will iterate through all virtual objects in the set, calculate their corresponding total value, and return the total resources to the player in one go after the sale is completed. This processing method integrates multiple separate settlements into a single atomic operation, significantly reducing system overhead and player waiting time. Furthermore, when a selected target virtual object is dragged into the judgment range of the sales area, an identifier for each selected target virtual object can be displayed within the judgment range of the sales area to indicate to the player the virtual object currently to be sold. Furthermore, if the player wants to cancel the sale before releasing their finger, they can move their finger away from the sales area to cancel the sale.

[0086] like Figure 4 As shown in an exemplary application of this embodiment, after entering the preparation stage of the second game stage, the graphical user interface displays the marked status (such as highlighted pieces) of multiple pieces (i.e., target first virtual objects) that were pre-marked in the first game stage. The player presses and moves three fingers on the screen to make all the marked pieces enter the selected state and move with the finger. When the three fingers move, the identifier of the selected piece and the total selling price can be displayed in the selling area. When the three fingers move to the selling area and are released, the system immediately performs batch selling processing on the pieces and updates the player's virtual object in the graphical user interface.

[0087] In an optional implementation, in response to a batch triggering operation, controlling the marked target first virtual objects to be in a selected state includes: in response to a preset touch operation on any one of the marked target first virtual objects, controlling all marked target first virtual objects to be in a selected state. In this way, a preset touch operation on any marked object can trigger all marked objects to enter a selected state, avoiding the tedious and time-consuming operation of clicking to select one by one, thereby significantly improving the triggering efficiency of batch processing and reducing the player's operational load.

[0088] Optionally, a preset touch operation is used to receive batch trigger commands from the user, so that the terminal controls all marked target virtual objects to uniformly enter the selected state. Optionally, the preset touch operation can be in the form of multi-finger touch gestures or key combination operations. Considering that selecting virtual objects one by one in the limited time of the preparation phase would bring a huge operational load and be prone to accidental touches, as a possible implementation, the above-mentioned preset touch operation on a mobile terminal can specifically be a three-finger gesture of pressing any position on the screen. When the system detects a three-finger touch signal, it will automatically block other regular click operations to ensure accurate recognition of batch selection commands. On a personal computer, the preset touch operation can be adapted to the coordination of keyboard key combinations and mouse actions, such as the Shift key plus mouse drag operation. It should be noted that the above operation method is only an example, and this application does not intend to exhaustively limit the specific form of touch operation. In actual implementation, other interaction methods that can trigger batch selection logic through a single action can also be configured according to the terminal type and user habits.

[0089] Optionally, in addition to the three-finger gestures and key combinations mentioned above, preset touch operations can be flexibly configured according to different application scenarios or user habits. As another implementation, the preset touch operation can also be a long press operation on any marked target virtual object accompanied by a dragging trajectory. That is, the player only needs to long press one of the marked pieces, and after the system determines that the press duration has reached a preset time threshold, it can recognize the press action as a batch trigger signal, thereby controlling all marked pieces to aggregate together. Similarly, on a personal computer, the above batch selection logic can be triggered by using the Ctrl key and left mouse button. If the user only performs a normal click without meeting the preset touch conditions, the system only selects the currently clicked single object, thus ensuring the convenience of batch operations while maintaining the independence of single-point operations.

[0090] Optionally, to further avoid unintended batch selection due to accidental touches, the preset touch operation recognition process can also incorporate parameter judgment and state locking mechanisms. In practice, the terminal not only detects the number of touch points or the combination of buttons, but also combines touch pressure values ​​or duration of continuous pressing for comprehensive judgment. For example, batch selection is only confirmed when three-finger touch is detected and the average pressure value exceeds a specified threshold. After confirming entry into the selected state, all marked target virtual objects on the interface can display aggregated animations and move with the current touch point. At this time, the system will temporarily suspend the response logic of other interface controls until the batch processing operation ends or is actively canceled. It should be understood that through this multi-dimensional parameter verification and state locking, it is possible to effectively distinguish between the user's tentative operations and true intentions, making the triggering of batch capture more stable and reliable.

[0091] According to one embodiment of the game control device of this application, a graphical user interface is provided through a terminal. The graphical user interface includes a virtual scene, such as... Figure 5 As shown, the device may include: The marking module 501 is configured to mark a target first virtual object in response to a selection operation for at least one first virtual object during the first game phase; wherein the at least one first virtual object is a virtual object configured to participate in the battle during the first game phase. Display module 502 is configured to display the marked state of the target first virtual object in the virtual scene during the second game phase; Processing module 503 is configured to perform batch processing on the marked target first virtual object in response to a batch processing operation.

[0092] In this way, by pre-marking virtual objects in the first game stage and performing batch processing in the second game stage, the high-frequency interactive operations that were originally concentrated in a single stage are distributed to different stages and aggregated into batch instructions. This reduces the number of operation steps and interaction frequency in the preparation stage, helps to avoid instruction redundancy caused by short-term high-frequency operations, reduces the instruction processing pressure on the terminal within a limited time window, and improves the data processing efficiency of the terminal.

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

[0094] 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 the exemplary embodiments of this application, 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.

[0095] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0096] The following is a detailed reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. 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.

[0097] 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 6Electronic 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.

[0098] In particular, according to one embodiment of this application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this application 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 application.

[0099] Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0100] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. 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. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0101] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application 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, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or 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. A game control method, characterized in that, The method includes providing a graphical user interface via a terminal, the graphical user interface containing a virtual scene, and the method comprising: In the first game phase, in response to a selection operation for at least one first virtual object, a target first virtual object is marked; wherein, the at least one first virtual object includes virtual objects configured to participate in combat during the first game phase; In the second game phase, the marked state of the target first virtual object is displayed in the virtual scene; In response to a batch processing operation, batch processing is performed on the marked target first virtual object.

2. The method according to claim 1, characterized in that, The first game phase is the battle phase of the target round, and the second game phase is the preparation phase for the next round of the target round.

3. The method according to claim 1, characterized in that, The step of marking the target first virtual object in response to a selection operation for at least one first virtual object includes: A marker interface is displayed, which displays at least one first virtual object; In response to a selection operation for at least one first virtual object displayed in the marking interface, the target first virtual object is marked.

4. The method according to claim 3, characterized in that, The position of the at least one first virtual object displayed in the marking interface is mapped to the initial position of the at least one first virtual object in the battle area of ​​the virtual scene at the start of the first game phase.

5. The method according to claim 1, characterized in that, The step of displaying the marked state of the target first virtual object in the virtual scene includes: The target effect is displayed in the graphical user interface to represent the marking status of the target first virtual object; wherein the target effect includes at least one of the following: the target first virtual object is displayed in a display style different from other first virtual objects in the combat area of ​​the virtual scene, and an indicator pointing from the marking control to the target first object.

6. The method according to claim 1, characterized in that, In response to a batch processing operation, batch processing is performed on the marked target first virtual object, including: In response to a batch trigger operation, the marked target first virtual object is controlled to be in a selected state; In response to a batch processing operation on a target first virtual object that is in a selected state, batch processing is performed on the marked target first virtual object.

7. The method according to claim 6, characterized in that, The step of responding to a batch trigger operation by controlling the marked target first virtual object to be in a selected state includes: In response to a preset touch operation on any of the marked target first virtual objects, control all the marked target first virtual objects to be in a selected state.

8. The method according to claim 1, characterized in that, The method further includes: In the second game phase, if the quality of the second virtual object in the marked target first virtual object meets the preset change conditions, the marking state of the second virtual object is canceled.

9. The method according to claim 1, characterized in that, The method further includes: In the second phase, in response to a target operation on a third virtual object within the marked target first virtual object, the marking state of the second virtual object is cancelled.

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 method as described in any one of claims 1 to 9.

Images