Information processing method and electronic device

Abstract

The present disclosure provides an information processing method and an electronic device, comprising: displaying a first game interface associated with a current game account through a graphical user interface, the first game interface comprising at least one functional area; determining a target functional area in the at least one functional area in response to an information broadcast triggering instruction; determining a target information type corresponding to the target functional area; obtaining target state data corresponding to the target information type for other game accounts, the other game accounts being game accounts other than the current game account in the current game session; and outputting target broadcast content generated based on the target state data. In this way, the rendering overhead and interaction redundancy generated by frequent interface switching can be reduced, the efficiency of obtaining state information can be improved, the data interaction frequency between the terminal and the server can be reduced, and the processing pressure of the terminal can be alleviated.

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 the technologies used in multiplayer strategy games, acquiring the status information of other participants is often necessary to aid in developing game strategies. These technologies typically provide each player with an independent game interface, requiring players to switch between interfaces to view the status data of other participants. For example, in some turn-based strategy game scenarios, players often need to frequently switch interfaces to observe their opponents' situations.

[0003] However, repeatedly switching interfaces causes the terminal to repeatedly load and render different game interfaces, which not only increases the processing burden on the terminal, but also intensifies the frequency of data interaction and signaling overhead with the server, which can easily lead to increased system resource consumption, limited information acquisition efficiency, and easy omission of key status data. Summary of the Invention

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

[0005] According to one aspect of this disclosure, an information processing method is provided, which provides a graphical user interface through a terminal device. The method includes: displaying a first game interface associated with the current game account through the graphical user interface, the first game interface including at least one functional area; in response to an information broadcast trigger command, determining a target functional area in the at least one functional area; determining a target information type corresponding to the target functional area; acquiring target status data corresponding to other game accounts and the target information type, wherein the other game accounts are game accounts other than the current game account in the current game; and outputting target broadcast content generated based on the target status data.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, which provides a graphical user interface through a terminal device. The apparatus includes: a display module for displaying a first game interface associated with the current game account through the graphical user interface, the first game interface including at least one functional area; a first determining module for determining a target functional area in the at least one functional area in response to an information broadcast trigger command; a second determining module for determining a target information type corresponding to the target functional area; an acquisition module for acquiring target status data corresponding to other game accounts and target information types, wherein other game accounts are game accounts other than the current game account in the current game; and an output module for outputting target broadcast content generated based on the target status data.

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

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

[0009] One embodiment of this disclosure provides an information processing method, comprising: displaying a first game interface associated with the current game account through the graphical user interface, the first game interface including at least one functional area; in response to an information broadcast trigger command, determining a target functional area within the at least one functional area; determining a target information type corresponding to the target functional area; acquiring target status data corresponding to other game accounts and the target information type, wherein the other game accounts are game accounts other than the current game account in the current game; and outputting target broadcast content generated based on the target status data. This helps reduce rendering overhead and interaction redundancy caused by frequent interface switching, improves the efficiency of acquiring status information, reduces the frequency of data interaction between the terminal and the server, and alleviates the processing pressure on the terminal. 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.

[0012] Figure 2 This diagram illustrates the structure of an information processing apparatus provided in one exemplary embodiment of the present disclosure. Figure 3 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

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

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

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

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

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

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

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

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

[0021] According to one embodiment of the information processing method of this disclosure, a graphical user interface is provided through a terminal device, and a first game interface associated with the current game account is displayed through the graphical user interface. The first game interface includes at least one functional area; such as... Figure 1 As shown, the method may include: Step S110: Display the first game interface associated with the current game account through a graphical user interface. The first game interface includes at least one functional area. Step S120: In response to the information broadcast trigger command, determine the target functional area in at least one functional area; Step S130: Determine the target information type corresponding to the target functional area; Step S140: Obtain target status data corresponding to other game accounts and target information types. Other game accounts are game accounts other than the current game account in the current game. Step S150: Output the target broadcast content generated based on the target state data.

[0022] According to one embodiment of this disclosure, it helps to reduce rendering overhead and interaction redundancy caused by frequent interface switching, improve the efficiency of obtaining status information, reduce the frequency of data interaction between the terminal and the server, and alleviate the processing pressure on the terminal.

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

[0024] In step S110, the first game interface associated with the current game account is displayed through a graphical user interface. The first game interface includes at least one functional area. In an optional implementation, a graphical user interface (GUI) is provided via a terminal device to display the first match interface associated with the current game account. The first match interface includes at least one functional area. This integrates at least one functional area within the same interface, providing a unified operational basis for subsequent screen-switching-free mirrored broadcasts, reducing the cognitive load and screen-switching frequency for players in multi-player scenarios.

[0025] In one implementation, after the player's smart terminal launches the game application, the graphical user interface loads and displays the first game interface associated with the current game account. This first game interface is fully rendered on the terminal screen, and its overall layout includes at least one functional area. This functional area is distributed as an independent interface sub-area around the perimeter or bottom of the first game interface, serving to display additional information or interactive entry points in addition to showcasing the local game situation. For example, when the first game interface adopts a landscape layout, the chessboard display area can be centered on the screen, while the functional areas are arranged around the sides of the chessboard display area, thus visually separating it from the main local operation area and ensuring the clarity of the interface information hierarchy. Of course, the chessboard operation area can also serve as a functional area.

[0026] Optionally, the aforementioned first game interface is used to present the local game main scene of the current game account, which includes at least a chessboard display area and one or more functional areas.

[0027] Optionally, the aforementioned first game interface can be the main operation interface corresponding to the current game account during an auto chess game. Besides displaying the standard chessboard grid and deployed virtual characters, it can also embed or overlay one or more functional areas on the edges or corners of the interface. In one specific presentation method, this first game interface has a homogeneous interface framework with the second game interfaces held by other players in the game; that is, both include a chessboard display area and surrounding functional auxiliary areas, but the first game interface primarily responds to the operation commands of the local player account. Considering that players need to frequently compare the differences between their own and others' lineups in multiple rounds of gameplay, using the first game interface as the trigger and display source for information broadcasts allows players to directly access and view the mirrored data of other players without leaving their own chessboard. In other words, the first game interface not only serves as a display of the local situation, but is also configured as the control center of the screen-free query system. Its displayed content and interactive boundaries can be dynamically adjusted according to the stage information of the current game process. For example, a more detailed economy and equipment panel is displayed during the preparation stage, while the visual proportion of some non-critical areas is weakened during the battle settlement stage.

[0028] Optionally, the presentation of the aforementioned first game interface is not limited to a fixed-view two-dimensional chessboard screen; it can be adaptively adjusted according to the hardware performance and screen size of the terminal device. In one embodiment, the first game interface can adopt a landscape layout, with the chessboard area centered and the player list arranged vertically on the right side of the screen, while functional areas are concentrated on the left side or bottom of the screen, thus providing reasonable touch space for players to operate with one or two hands. Furthermore, some visual elements of the first game interface can automatically adjust their display level in response to changes in the game state. For example, when entering the match prediction broadcast node, the system can generate a semi-transparent overlay at the top of the first game interface, highlighting all selectable functional areas to guide players to complete subsequent operations.

[0029] Optionally, the aforementioned functional areas are distributed around the perimeter of the first game interface, used to receive player actions and trigger corresponding information broadcasts. Optionally, the aforementioned functional areas may include various interactive sub-areas with different information-carrying attributes, and their specific forms can be flexibly set according to the tactical needs of the game. In one embodiment, this functional area may be an interest ball area related to the game's economic attributes; players can trigger a mirror broadcast of the current level and gold holdings of all or some other players by dragging virtual interactive elements to this area. In another embodiment, this functional area may also be an equipment slot area related to equipment attributes, with its broadcast content corresponding to the equipment fragments or finished equipment remaining in other players' equipment slots. Furthermore, the aforementioned functional areas may also cover a synergy overview area related to lineup attributes; the system can use this area to call the artificial intelligence analysis module, comprehensively considering the virtual characters and equipment configurations of other players, and output lineup prediction broadcasts. It should be noted that the above description of the classification of functional areas and the corresponding broadcast content is only one example. In actual implementation, other functional modules with specific tactical indication significance, such as a win streak record area or a shop refresh probability area, can be added according to the iteration needs of the game version.

[0030] Optionally, the functional attributes corresponding to the aforementioned functional areas can be configured to include single-dimensional tactical information or to simultaneously cover composite status data across multiple dimensions. In one implementation, when a functional area is configured as a composite area possessing both in-game economic attributes and lineup attributes, the system can output other players' economic overviews and lineup strength assessments sequentially or in a paginated format after a single drag-and-drop trigger. It should be noted that the mapping relationship between different functional areas and the types of information to be broadcast can be preset by the game client in the installation package or dynamically replaced based on the player's custom configuration before or during the game. For example, a player can rebind the interest ball area, originally mapped to economic broadcasts, to an equipment broadcast entry, and bind the win / loss relationship area to a win / loss streak broadcast entry. At the specific mapping logic execution level, the system can query the local or server-side mapping table based on the unique identifier of the selected functional area in the graphical user interface, thereby accurately converting the target functional area into the corresponding target information type. Furthermore, the above mapping relationship can also support cloud-based hot updates of the version, allowing newly added tactical dimensions to be quickly integrated into the existing functional area framework without having to reconstruct the overall layout of the first game interface.

[0031] In an optional implementation, the first game interface displays a player list, which includes player identifiers corresponding to other game accounts. The method further includes: in response to a selection operation on the first player identifier in the player list, switching the currently displayed first game interface to the second game interface associated with that first player identifier. This approach, while retaining the main flow of intelligent broadcasting without screen switching, provides players with a quick path to switch screens on demand to view the complete battle situation of a specific opponent, while also catering to the need for in-depth information acquisition, making the interaction method more flexible and diverse.

[0032] In one implementation, the right edge of the first game interface displays a vertically arranged list of players, where each player identifier includes an opponent's avatar, real-time ranking number, and current survival status. When a player wishes to directly observe a particular opponent's complete board layout and equipment details, they can perform a single-click selection operation on the target player identifier. In response to this selection operation, the terminal device smoothly switches the first game interface rendered in the current graphical user interface to the second game interface associated with the first player identifier, with the switching process presented as a horizontal slide-in animation. Furthermore, a return control is provided in the upper left corner of the second game interface. After triggering the return control, the player can switch back to their own first game interface, thus allowing them to consider both the overall battle situation and in-depth information about a specific opponent during the game.

[0033] Optionally, the player list can be located on the right edge of the first match interface, or on the left edge, top edge, or other locations. Its display format can be a vertically arranged strip panel, a grid, or a folding drawer panel. The player icons in the list are arranged according to the current ranking of the match, or dynamically adjusted according to the remaining health of players from highest to lowest or lowest to highest. To avoid accidental interface switching due to accidental touches on player icons during intense battles, the player list can be set to a semi-transparent state or folded to the edge of the screen during specific match phases, only fully displayed after receiving a preset unfolding trigger signal. In addition to displaying the player icons, the player list can also include auxiliary content such as match history thumbnails or network latency indicators. It should be noted that the above description of the player list's location and display content is only one example. In actual implementation, it can be adapted according to the screen ratio of the terminal device or operating habits. This disclosure is not intended to limit the form of the list.

[0034] Optionally, considering that players may frequently need to view details of multiple opponents during a match, performing a complete "back" and "re-enter" operation each time would significantly increase the operational burden. As a possible implementation, the player list can remain permanently displayed at any time, or it can be automatically hidden after the match enters a certain stage to reduce visual interference. Furthermore, after a player obtains a lightweight mirror image of an opponent by dragging the smart broadcast button, if they wish to view the opponent's complete board details, they can directly locate the player's identifier in the player list and perform a selection operation. The display parameters of this player identifier can be linked to the broadcast status. For example, when a player has just been covered by a mirror broadcast, the edge of their corresponding player identifier can briefly show a highlighted border to indicate that the opponent's information has been recently acquired. In other words, the player list not only serves as an entry point for traditional screen-switching operations but can also complement the screen-switching-free broadcast mechanism, allowing players to freely switch between lightweight browsing and in-depth viewing according to their needs.

[0035] Optionally, the second match interface is the complete interface of another game account currently engaged in a match, displaying the functional areas and status data corresponding to that account. Alternatively, the second match interface is the complete chessboard interface associated with another game account in the current match, rendering the virtual character currently deployed by that account, equipment accessories, and real-time battle animations. This second match interface has the same or similar functional area layout as the first match interface, such as including an economic broadcast area, equipment display area, and synergy information area, to ensure consistent cognitive habits for players across multiple interfaces. It should be noted that the second match interface can be a full-screen display mode that directly replaces the first match interface, or it can be a partially enlarged window superimposed on the first match interface in a picture-in-picture format. To avoid visual abrupt changes during interface switching that could cause players to lose their rhythm of the current match, a smooth transition animation can be inserted when switching from the first match interface to the second match interface, such as a horizontal slide-in or fade-in / fade-out effect. The above-described display method of the second game interface is only an example. In actual implementation, the rendering accuracy can be dynamically adjusted according to the performance parameters of the terminal device or the network conditions. This disclosure is not intended to limit this.

[0036] Optionally, the selection operation is used to trigger a selection command to switch the first game interface to the second game interface corresponding to the target player's identifier. Optionally, the selection operation for the first player identifier in the player list can be a single click on the avatar area corresponding to the player identifier, or a combination of double-click confirmation or long-press to trigger the switch. This disclosure does not limit the specific touch control method.

[0037] In an optional implementation, the first game interface is the game interface for the current game account to play against a second game account from another game account. In this way, opponent information can be broadcast directly from the game interface, seamlessly connecting pre-battle intelligence gathering and local decision-making within the same visual framework, avoiding operation interruptions and distractions caused by screen switching.

[0038] In one implementation, when the current game enters a battle round, the first game interface is the battle interface between the current game account and the second game account. At this time, the system has determined the second game account from other game accounts according to the matching rules. The first game interface maintains the chessboard view of the current game account, and at the same time identifies the second game account in the battle status bar in the form of an avatar or name.

[0039] Optionally, the second game account is a specific account that forms a combat relationship with the current game account in the current battle round. It is determined according to the matching rules and displayed in the first game interface. Optionally, in the above battle scenario, the second game account refers to the specific combat opponent corresponding to the current game account in the current battle round. It can be determined by the system randomly or sequentially assigning it according to the matching rules in the list of surviving players before the battle. The identity of the second game account can be graphically displayed in the top battle information bar of the first game interface, or it can be associated with the current battle process as low-level data without being explicitly displayed. Furthermore, considering the characteristic of multi-player rotation in auto chess games, the above-mentioned second game account can change as different battle rounds progress. That is, the current round corresponds to a certain player account, and the next round may correspond to a different player account. However, the first game interface always maintains a presentation format based on the current game account's perspective, thereby ensuring that the triggering environment of the mirror broadcast is stable within the same visual framework and avoiding the loss of operational continuity caused by the switching of interface perspectives. It should be noted that the above description of the second game account is only an example. In actual implementation, the second game account can also be mirror data generated by the system or a virtual enemy account in the round of monsters. This disclosure is not intended to limit it.

[0040] In step S120, in response to the information broadcast trigger command, a target functional area is determined in at least one functional area. Thus, by establishing a directional response mechanism between the information broadcast trigger command and the functional area, the target functional area is quickly locked.

[0041] In one implementation, the terminal device displays the first game interface associated with the current game account through a graphical user interface. This first game interface includes multiple functional areas such as an economy display area, an equipment display area, and a team composition synergy area. When the game status information monitoring module detects that the game has entered the preparation countdown phase, it automatically generates an information broadcast trigger command and distributes it to the client's main thread. Upon receiving this command, the interaction layer first switches each functional area to a selectable state, at which point a semi-transparent white outline appears around the economy display area. Subsequently, based on the area type marker carried in the command, the system identifies the economy display area as the target functional area so that it can subsequently retrieve the corresponding economy area status data from the game interfaces of other game accounts.

[0042] Optionally, this instruction is used to activate the broadcast process based on the game status or user operation. The generation method includes automatic system triggering and manual triggering. Optionally, the generation source of the above-mentioned information broadcast trigger instruction includes at least two different paths. One is the trigger path generated by the system automatically monitoring game status information. Under this path, the system background tracks the current game's stage nodes, resource changes, or win / loss sequences in real time. When a node that meets the preset broadcast conditions is detected, the system automatically generates and sends the information broadcast trigger instruction to the client. The other path originates from the user's active triggering of virtual interactive elements. When a player performs a click, long press, or drag operation on a specific control in the graphical user interface, the interaction layer captures the operation event and encapsulates it into the above instruction. It should be noted that the data format of this instruction is not limited to a fixed structure. It can be represented as a lightweight data packet carrying a region identifier, broadcast type identifier, and timestamp, or as a minimal signal containing only a trigger flag. In actual transmission, this instruction can be centrally issued by the game server or generated by the local logic layer of the terminal device according to caching rules. This embodiment sets up diversified instruction generation channels to ensure that key game nodes are not missed, while giving players full initiative in their operations, so that the timing of information acquisition matches the rhythm of the player's tactical thinking.

[0043] Optionally, considering that multiple information broadcast trigger commands may arrive consecutively within the same session period, the above method can further include command queue management logic to avoid interface response conflicts or overlapping broadcast content. Specifically, after receiving a new information broadcast trigger command, the terminal device first checks whether there are any preceding broadcast tasks that are currently being executed or have not yet been rendered. If a preceding task exists and its type is the same as the new command, the latest status data carried by the new command can overwrite the pending items in the queue to ensure that the information obtained by the player is timely. If the preceding task types are different, the system decides whether to execute it in the queue or to queue it sequentially according to a preset priority strategy.

[0044] Optionally, the process of determining the target functional area includes at least two sub-stages: state activation and area locking. In the state activation stage, in response to the information broadcast trigger command, multiple functional areas in the graphical user interface become selectable. The boundaries of each functional area can be visually indicated through a semi-transparent outline, highlighted stroke, or a small-scale animation to inform the player of the range of candidate areas currently available for broadcast. In the area locking stage, the system determines a functional area as the target functional area from the candidate areas in the selectable state based on the source of the command or subsequent player actions. Considering that players may accidentally tap during fast-paced matches, as a possible implementation, when the system detects that a player has consecutively hit two or more functional areas within a preset time threshold, it can default to selecting the functional area closest to the action landing point as the target functional area, or determine the last hit functional area as the target functional area. It should be noted that the location of the target functional area in the first match interface is not limited; it can be the equipment display area at the bottom of the interface, the win / loss relationship area on the side, or the economy ball display area located slightly below the center.

[0045] In an optional implementation, in response to an information broadcast trigger command, a target functional area is determined within at least one functional area, including: in response to a specified operation, controlling at least one functional area in the first game interface to enter a selectable state; and in the selectable state, in response to a selection operation for at least one functional area, determining the target functional area. Thus, by adding a selectable state transition mechanism before entering area selection, players can accurately lock onto the functional area to be broadcast under visual guidance, not only reducing the risk of accidental touches in screen-switching scenarios but also effectively improving the certainty of information selection and the continuity of operation.

[0046] In one implementation, during the first phase of the game, the player performs a specified operation, and the system immediately switches multiple functional areas within the game board area to a selectable state in batches. At this time, the boundaries of each functional area are highlighted and identifiable. Based on this, the player continues to perform a selection operation on a target functional area, and the system then determines the target functional area based on the touch point, serving as the spatial basis for subsequent information type mapping and state data retrieval. The highlighted form can be represented as a semi-transparent white outline, or as a gradual transition of the area's background color from a normal dark state to a light gray state; this disclosure does not limit this.

[0047] Optionally, a specified operation is used to initiate a state switching request to the system, thereby triggering the functional area in the first game interface to enter a selectable state.

[0048] Optionally, the specified operation can be a trigger action performed by the player on a specific virtual interactive element in the first game interface. In a specific implementation, the virtual interactive element can be configured as a circular touch button that floats on the edge of the graphical user interface. After the player presses and holds the button for a valid duration determined by the system (e.g., 0.5 seconds, 1.0 seconds, or 1.5 seconds, etc.), the system determines that the specified operation is successful and then sends a state switching command to the interface rendering layer, making each functional area selectable. It should be noted that the form of the virtual interactive element is not limited to a circular button; it can also be a bar toolbar, a semi-invisible hotspot, or a side widget bound to the player's avatar, as long as it can be perceived and triggered by the player.

[0049] Optionally, considering the ease of operation for players in different grip postures, the aforementioned designated operation can also be completed through gesture path recognition. As one possible implementation, the player draws a geometric trajectory on the screen that matches a matching template (e.g., a diagonal path sliding from the lower left corner of the screen to the center, or drawing a closed circular pattern). The system collects touch coordinate sequences in real time and performs template matching. If the matching similarity reaches a system-set threshold (e.g., 70%, 85%, or 90% of the matching score), a state switching command can be generated. Furthermore, in addition to manual triggering, the system can also receive voice input or external device button input as alternative sources for the designated operation in specific scenarios. For example, the player can speak a pre-configured wake-up phrase or press a function key on an external controller, thus accommodating multimodal interaction needs. In other words, this disclosure does not aim to limit the designated operation to a specific physical action; any input form that can be interpreted by the system as a control intention to enter a selectable state falls within the scope of the aforementioned designated operation.

[0050] Optionally, to prevent frequent triggering of specified operations from causing the interface state to repeatedly oscillate between the normal display and the selectable state, thereby interfering with the player's normal in-game vision, the system can initiate a short-term lock window after receiving a valid specified operation. During the duration of this lock window, even if another input stream matching the specified operation is detected, the system will ignore it or add it to the waiting queue until the current functional area has completed the determination of the target functional area and exited the selectable state. It should be understood that the specific value of this lock duration can be automatically adjusted by the system according to the stage of the game (for example, setting a longer unlocking waiting period during the preparation phase), or it can be configured by the player in the settings panel. By introducing this anti-jitter mechanism, on the one hand, it can avoid continuous accidental touches caused by the player's tense operation, and on the other hand, it can make the timing logic of state switching clearer and more controllable, ensuring that every transition from the normal state to the selectable state is meaningful and has a complete interactive loop.

[0051] Optionally, selectable states are designed to indicate that a functional area has entered a candidate state, which can be visually represented by highlighting the area border or adjusting the transparency.

[0052] Optionally, the aforementioned selectable states can be visually implemented as semi-transparent outlines around the edges of each functional area. Specifically, after the system responds to a specified operation, the interface rendering module can traverse all or part of the functional areas in the first game interface, overlaying a glowing outline or inner shadow effect onto these areas. The outline color can be a high-contrast color (such as a low-saturation ice blue or light gold) that contrasts with the current game theme color, thus clearly conveying the semantic meaning of being in the candidate area without affecting the player's ability to read the core data within the area. It should be noted that, in addition to visual presentation, selectable states can also be accompanied by tactile feedback (such as a short vibration of the terminal device) or subtle sound effects to form a multi-channel status notification mechanism, enhancing the certainty of the interaction.

[0053] Optionally, the selection operation is used to lock a target functional area in a selectable state, and its reception form includes single-point touch or swipe trajectory landing point confirmation. Optionally, the above selection operation can be a single-point touch action performed by the player on a functional area on the screen in a selectable state. In a specific implementation, after the system collects the coordinates of the player's touch landing point, the interface interaction layer first determines whether the coordinates are within the boundary range of a certain functional area; if the determination result is true, the functional area is recorded as the target functional area, and at the same time, a visual transition from the selectable state to the selected state of the area is triggered (for example, the outer frame color changes from light blue to bright orange-yellow, or a confirmation ripple animation appears inside the area). That is to say, the essence of the selection operation is to convert the player's spatial touch intention into a deterministic area selection command. On the other hand, in order to avoid landing point deviation due to finger obstruction, the system can also display an auxiliary positioning mark that moves with the touch point in real time during the stage when the player presses the touch but does not lift it, so that the player can check the selection position that will take effect before lifting the finger, thereby reducing the probability of mistakenly selecting adjacent areas.

[0054] Optionally, in addition to single-point touch, the selection operation described above can also be implemented through the endpoint of the swipe trajectory. In one implementation, after long-pressing a virtual interactive element, the player does not release their finger but continues to swipe above the target functional area before releasing it. The system uses the touch coordinates at the moment of release as the selection basis, determining the functional area where those coordinates are located as the target functional area. It should be understood that this swipe-release mode, compared to the single-point mode, has the advantage of completing both the triggering of the specified operation and the execution of the selection operation with a single continuous touch, reducing the time cost for players to switch hand shapes between different interactive elements.

[0055] Optionally, the target functional area is the selected functional area to be broadcast, and its functional attributes directly determine the mapping direction of the subsequent target information type. When a player selects one of multiple selectable functional areas, the system marks the selected functional area as the target functional area at the data level and writes its area identifier code into the context cache of the current broadcast task so that the corresponding target information type can be queried later based on the mapping relationship. In one implementation, if the player selects the interest ball display area, the target functional area is assigned an economic functional attribute code; if the player selects the equipment display area, the target functional area corresponds to an equipment functional attribute code.

[0056] In an optional implementation, the specified operation is a trigger operation for virtual interactive elements in the first game interface, and the selected operation is a swipe operation from the virtual interactive element to any functional area. In this way, by using a dedicated interactive entry on the screen in conjunction with the swipe gesture, players only need to drag once to confirm the target functional area and trigger the subsequent mirror broadcast process, which significantly reduces the number of screen switches and memory costs, and improves the efficiency of information acquisition in the game.

[0057] In one implementation, a semi-transparent circular virtual interactive element is permanently displayed in the lower right corner of the first game interface as a smart broadcast button. When a player needs to view the economic status of other opponents, they first press the circular button and keep their finger on the screen. At this time, the system recognizes the continuous press trigger and switches each functional area to a selectable state, with a highlighted semi-transparent frame appearing around each area as a landing point indicator. Subsequently, the player performs a selection operation: their finger slides from the circular button position to the interest ball area on the left, and a semi-transparent trajectory line follows the movement of the finger. When the end of the finger's sliding trajectory falls within the outer frame of the interest ball area, the player releases their finger, and the system confirms that the interest ball area is the target functional area, thus completing the selection of the information broadcast area based on a single continuous gesture.

[0058] Optionally, virtual interactive elements are used to receive player-triggered actions to evoke a selected state for information broadcasting and serve as the starting point for swipe operations.

[0059] Optionally, the virtual interactive element can be a semi-transparent display control placed at the edge of the first game interface, or a temporary interactive entry point invoked via gestures or shortcut keys. In one implementation, the element appears as a circular floating button permanently located in the lower right corner of the player's board. Its visual hierarchy is lower than the main combat control area but higher than the background scene, thus avoiding obstructing the core game view while ensuring that the player can reach it at any time. Considering that players need to quickly initiate queries during intense games without precisely aiming at tiny targets, the touch response area of ​​the aforementioned virtual interactive element can be larger than its actual display area. For example, the icon itself may have a diameter of 48 pixels, while the actual triggerable range is a circular hotspot with a diameter of 80 pixels. When the player presses the virtual interactive element, the interface immediately enters a selectable state. At this time, the outer frame of each functional area changes from hidden to highlighted or flashing like a breathing light, intuitively indicating to the player the effective range of the draggable landing point. It should be noted that the visual form of this virtual interactive element is not limited to a circular floating button. It can also be represented as a draggable card, a miniature chess piece, or a tab bar with dynamic guide arrows, as long as it can be recognized by the player as the starting point for initiating the mirror broadcast interaction.

[0060] Optionally, the swipe operation aims to move the virtual interactive element from its initial position to the target functional area to complete the selection and triggering of the mirrored broadcast information type. Optionally, the above swipe operation can be manifested as a drag gesture of continuously pressing the virtual interactive element on the touch screen and then swiping in any direction, or it can be a combination of click and drag using a trackpad or mouse pointer. In actual gameplay, after the player starts swiping from the virtual interactive element, the interface will draw a semi-transparent trajectory line in real time following the finger position. When the finger hovers over a functional area, the light effect of that area changes from normal highlighting to enhanced flashing. At the same time, a miniature preview label dynamically appears near the virtual interactive element, indicating the broadcast information type corresponding to that area. For example, when hovering over the equipment area, it displays "View other players' equipment". Considering that every movement of the player's perspective during the game may affect decision-making efficiency, the entire path of the above swipe operation is constrained within the visible range of the first game interface, and the swipe endpoint does not need to fall precisely at the geometric center of the functional area. As long as the landing point when the finger is released is within the edge response band of the area, the system considers it a valid hit. It should be noted that the direction of the swipe operation is not limited. It can be a long drag diagonally across the board or a short movement from the edge control to the adjacent area. The physical path length and direction are determined by the player's grip on the device and the layout of the game interface.

[0061] In an optional implementation, the method further includes: monitoring the game status information on the first game interface, and generating an information broadcast trigger command when the game status information meets preset broadcast conditions. In this way, the system can automatically activate information broadcasts at key game nodes, reducing the frequency of manual player operations, minimizing operational interruptions, and improving the real-time and smoothness of information acquisition.

[0062] In one implementation, the system can monitor the game status information associated with the first game interface in real time at a preset period. When it detects that the current game process has switched from the non-gain selection phase to the gain selection phase and continues to stably exceed a preset threshold, it determines that the game status information meets the preset broadcast conditions, thereby automatically generating a corresponding information broadcast trigger command. The gain selection area can be identified as the target functional area so that the selection status of other accounts at this phase can be displayed to the current player. Based on this, at key points where the current player needs to focus on global strategy information, the system can proactively complete information collection and broadcast wake-up, preventing the player from missing crucial opportunities due to focusing on board operations.

[0063] The game status information reflects the current stage of the game and the occurrence of key events in real time, and its specific content changes dynamically according to the game progress. Optionally, the game status information can be information representing the game stage of the game account corresponding to the current first game interface. Considering that auto chess games usually contain multiple continuous and differentiated stages, such as preparation stage, battle stage, draft stage, and buff selection stage, as a possible implementation, the game status information can include the current stage identifier and sub-state identifiers within that stage. The stage identifier is used to distinguish the macro-level progress of the game, while the sub-state identifiers are used to further refine different time nodes within the same large stage. For example, the buff selection stage can be further subdivided into a selection waiting period and a selection confirmation period. The acquisition method of this game status information can also be diversified. It can be obtained by periodically polling the stage synchronization data sent by the game server, or it can be calculated and identified in real time by the terminal device according to the local game logic. One objective of this embodiment is to improve the precision of state monitoring by combining macroscopic stages with microscopic sub-states, thereby avoiding the generation of broadcast trigger commands at unnecessary times. On the other hand, it can also provide a data foundation for the fine-grained matching of subsequent broadcast content, thus making the automatic triggering mechanism more in line with the actual game rhythm.

[0064] Optionally, in addition to the aforementioned status information used to characterize the game's operational phase, the game status information may also include matchmaking information between the current game account and the opponent's account. That is, when the terminal device detects that the current game account is about to enter a match against a specified opponent's account, it can determine that the game status information has changed to meet specific conditions. In practical applications, this matchmaking information can be proactively pushed to the terminal by the server after the match round is determined, or it can be predicted by the terminal based on a locally stored match round table. Furthermore, the aforementioned game status information may also simultaneously include the player's real-time attribute information, such as the current population, the number of deployed pieces, or the number of active player synergies. The system can comprehensively consider the phase information, matchmaking information, and real-time attribute information to determine whether the preset broadcast conditions are met. It should be noted that the above description of the specific composition of game status information is only one example. In actual implementation, it can be adaptively adjusted according to the specific game rules and information broadcasting requirements of Auto Chess. This disclosure is not intended to limit the scope of game status information.

[0065] The preset broadcast conditions are designed to define the conditions under which information broadcast trigger commands need to be generated, and can be flexibly configured according to different game stages or event types.

[0066] Optionally, the aforementioned preset broadcast conditions can be a set of trigger rules corresponding to the stage identifiers in the game status information. For example, the preset broadcast conditions may include, but are not limited to: the game status information indicating that the current game has switched from a non-gain selection stage to a gain selection stage; the game status information indicating that the current game has switched from a non-combat stage to a pre-combat preparation stage; or the game status information indicating that the current game account has been matched with an opponent for the next round. To avoid false triggers due to instantaneous fluctuations in stage switching or network latency, the aforementioned preset broadcast conditions can also be configured with a stable duration requirement, meaning that a certain game state must remain continuously and stably above a preset threshold to be considered as meeting the broadcast conditions. By configuring differentiated trigger conditions for different game stages, on the one hand, the timeliness of key node broadcasts can be ensured, and on the other hand, excessive information interference can be avoided during periods when players are highly focused on operations.

[0067] In step S130, the target information type corresponding to the target functional area is determined.

[0068] Optionally, a preset mapping relationship can be used to quickly locate the target information type corresponding to the target functional area. This mapping relationship refers to the relationship between each functional area and the type of information to be broadcast. Upon receiving a broadcast trigger command, the system can directly invoke this mapping relationship to quickly match the target information type corresponding to the target functional area, effectively shortening the information matching time and improving the accuracy of the broadcast direction. For example, after the system identifies the target functional area as the interest ball area, it determines the game economy broadcast type corresponding to that functional area as the target information type based on the established mapping relationship; or, when the target functional area is the equipment display area, it determines the equipment retention broadcast type as the target information type based on the same mapping relationship, thereby clarifying the data categories to be collected and presented subsequently.

[0069] Optionally, the target information type can be at least one of the following: game economy broadcast type, equipment retention broadcast type, lineup prediction broadcast type, or core combat power broadcast type, which is dynamically determined based on the functional attributes of the target functional area. Specifically, the economy broadcast type indicates the current level and interest orb activation status of other game accounts, and other economic data; the equipment retention broadcast type indicates the items retained by other game accounts in the equipment area. Further, if the target functional area corresponds to the synergy display area, the target information type can be determined as the lineup prediction broadcast type, which combines information on other game accounts' deployed units, currently held units awaiting deployment, and equipped items to predict their potential lineup system; if the target functional area corresponds to the board deployment area, the target information type can be determined as the core combat power broadcast type, used to indicate the core damage-dealing units and core defensive units currently deployed by other game accounts. It should be noted that the above classification is only one example. In actual implementation, it can be adapted and expanded according to the game stage or gameplay mode. For example, in the later stage, an opponent counter relationship broadcast type can be added to further enrich the information dimension of the screen-free broadcast and enhance the depth of game strategy assistance.

[0070] In an optional implementation, determining the target information type corresponding to the target functional area includes: for each functional area in at least one functional area, determining the type of information to be broadcast corresponding to the functional attribute based on the functional attribute of the functional area in the first game interface. In this way, by configuring differentiated functional attributes for functional areas, a semantic mapping index between interface areas and the information to be broadcast is established, enabling the system to automatically match the corresponding data type based on the area's function, significantly improving the accuracy and intelligence of information broadcasting.

[0071] As one implementation method, the interest ball area in the first game interface displays the current game account's gold and interest information. The system categorizes this area as a game economy attribute based on its functional attributes, and accordingly determines the associated information to be broadcast as the level and deposit data of other game accounts. Similarly, for the area on the chessboard displaying one's own pieces, the system identifies its functional attribute as a lineup attribute, thereby determining the status of the opponent's main damage dealer and main tank units to be broadcast. Thus, players can obtain the enemy's dynamics semantically matched to the selected area by dragging a portion of the screen without switching screens.

[0072] Optionally, functional attributes are used to characterize the interactive or information display functions of the corresponding functional area in the first game interface, and serve as semantic indexes to match the type of information to be broadcast with the same direction.

[0073] In optional implementations, the functional attributes include at least one of the following: match economy attributes, equipment attributes, team composition attributes, and match win / loss attributes. Thus, by dividing the functional area according to match economy, equipment, team composition, and win / loss dimensions, the mirrored broadcast can accurately match player intent, improving information acquisition efficiency and reducing cognitive load.

[0074] The following explanation uses an auto chess game scenario as an example: In one implementation, the interest ball area in the graphical user interface has game economy attributes. When a player drags the smart broadcast button to this area and releases it, the terminal queries the game economy status data corresponding to other players' accounts, including the current level, the amount of gold held, and the interest activation status, and displays it in the target window. In another implementation, the equipment synthesis area has equipment attributes. After dragging, it broadcasts the types and quantities of equipment remaining in other players' equipment areas. Furthermore, the synergy display area has lineup attributes. The system combines the database to predict other players' lineup tendencies and renders the prediction results. In addition, the win / loss record area has game win / loss attributes. It broadcasts other players' recent winning or losing streaks and distinguishes different win / loss states with color coding in the target window.

[0075] Optionally, the game's economic attributes are used to characterize the information dimensions of resource accumulation and level growth in functional areas, supporting targeted queries and broadcasts of economic status data.

[0076] Optionally, the status data associated with the game's economic attributes may include, but is not limited to, parameters such as the level values, total gold coins held, and interest ball activation status of other game accounts in the current game. In one implementation, when a virtual interactive element controlled by the player is slid to a functional area with this attribute and triggers a broadcast, the terminal device requests the economic panel data corresponding to all other accounts in the game besides the current player from the server or local cache, and renders the retrieved levels and gold coin amounts in a combination of numbers and progress bars in the target window. The activation status of the interest ball can be distinguished by a highlighted icon or colored block. It should be noted that the specific types and presentation methods of the economic parameters mentioned above are only one example. In actual implementation, the parameter range can be adaptively adjusted according to the game version or specific season rules. This disclosure is not intended to limit the coverage of the game's economic attributes. By making the economic dimension an independent functional attribute, players can quickly grasp the opponent's development rhythm without switching screens, and it also provides basic data support for subsequent intelligent summarization of the game situation.

[0077] Optionally, considering the different focuses players place on economic information at different stages of the game, as a possible implementation, the target state data corresponding to the aforementioned game economic attributes can be dynamically expanded to derived indicators such as consumption records or upgrade differences. For example, in the mid-to-late stages of the game, in addition to displaying other players' static gold reserves, the target window can further calculate and display comparative parameters such as the level difference and interest income gap between them and the current player. These parameters can be calculated in real time based on preset benchmark data. To avoid information overload leading to overly cluttered content in the broadcast window, when multiple indicators in the target state data simultaneously meet preset threshold conditions, the system can prioritize rendering only the key leading or lagging indicators to highlight the game situation information. Furthermore, the functional area mapped by the game economic attributes is not limited to the interest ball area; it can also include the shop refresh control or experience bar area, as long as the area serves the function of displaying resource-related information in the interface layout.

[0078] Optionally, equipment attributes serve as an information dimension representing the configuration and retention status of virtual items in the functional area, supporting targeted querying and broadcasting of equipment status data. Optionally, the target status data associated with equipment attributes may include, but is not limited to, the types, quantities, and crafting paths of virtual items currently held but not equipped by other game accounts. In one implementation, when a player drags the smart broadcast button to the functional area with equipment attributes in the first game interface, the terminal determines that the target information type is equipment information, and then queries the status data of other player accounts in the equipment bar of the second game interface. The presentation of the aforementioned status data in the target window can be diverse, at least partially including visual content such as equipment icon matrices, rarity indicators, and crafting scroll prompts, used to distinguish and indicate differences in equipment reserves among different players. Furthermore, considering the close relationship between equipment combinations and team strength, the system can also perform preliminary analysis of the aforementioned equipment status data. If it detects that other players have collected a complete set of key completed equipment pieces, a prompt indicator is added to the target broadcast content. It should be noted that the equipment attributes covered are not limited to the fixed equipment pool in the current season version, but can also be adapted to seasonal equipment or event-limited items added later.

[0079] Optionally, the lineup attribute is used to characterize the information dimension of the combination of combat units and tactical relationships in the functional area, supporting targeted query and prediction of lineup status data. Optionally, the target status data associated with the lineup attribute not only includes the list of combat units currently deployed by other game accounts, but can also combine the synergy rules and equipment associations in the database to predict and deduce the tactical combinations that other players may form. In one implementation, when the target functional area is identified as having a lineup attribute, the system obtains the card holdings of other players, the deployed units and their positions, and calls a pre-trained analysis model to comprehensively analyze the above multi-source data to generate a lineup prediction result. The prediction result can be displayed in the target window by directly listing the predicted lineup name and core units, or by presenting the confidence distribution of multiple possible lineups in the form of a probability cloud map. Among them, when the analysis model makes a lineup prediction, in addition to referring to the currently visible deployed units, it will also take into account the equipment configuration with obvious directional characteristics in the equipment area. For example, if a special equipment that is only applicable to ranged output units appears in the equipment area, the probability weight of that player going for a ranged core lineup will be increased accordingly. It should be noted that the prediction logic of lineup attributes does not rely on a single algorithm. As long as it can realize the function of inferring the opponent's tactical intentions based on multi-dimensional data, it falls within the protection scope of this disclosure.

[0080] Optionally, considering the uncertainty of lineup prediction results due to early game stages or opponents deliberately concealing their strategies, to avoid excessive prediction bias caused by data sparsity, the above method can also evaluate the prediction confidence of the analysis model output before outputting the target broadcast content. If the confidence is lower than a preset threshold, in addition to displaying the predicted lineup in the target window, a prompt can be added to indicate that the reference value of the current prediction result is limited. In another implementation, the functional area mapped by the lineup attributes can not only be the traditional synergy display area, but also the position area where the core output units of the board are located. When the player drags the virtual interactive element to the position area, the system directly broadcasts the details of the core output and tank units in the corresponding positions of other players, such as the star rating and cost color of two main DPS and two main tank units. In addition, to enhance the hierarchical presentation of information, the target window can display verified lineup information and predicted lineup information in sections, and help players quickly distinguish between factual data and inferred data through visual style differences. This design can reduce the cognitive load of players memorizing and comparing lineups on the one hand, and provide players with more forward-looking reference for game decisions on the other hand.

[0081] Optionally, the match win / loss attribute is used to represent the information dimension of historical wins / losses and winning / losing streaks in the functional area, supporting targeted querying and broadcasting of win / loss status data. Optionally, the target status data associated with the match win / loss attribute may include, but is not limited to, the win / loss records, cumulative winning streaks, or losing streaks of other game accounts in the current match over the past few rounds. In one implementation, when a player drags the smart broadcast button to the functional area with the match win / loss attribute, the terminal device queries the win / loss relationship data of other player accounts in the last five rounds of the game and renders and displays it in the target window in the form of a timeline or list. Among them, for players in a winning or losing streak, the target broadcast content, in addition to displaying the basic win / loss indicator, can also highlight the specific number of matches in their winning or losing streak, and visually enhance it through color coding or dynamic effects, so that players can quickly identify opponents who pose a greater threat or are in a disadvantageous comeback phase in the current match. It should be noted that the above-mentioned range of win / loss data is not limited to five matches, and can be dynamically adjusted according to the total number of rounds in the game mode or the system load in actual implementation.

[0082] In step S140, target status data corresponding to other game accounts and target information types are obtained. Other game accounts are game accounts other than the current game account in the current game. In this way, by selectively capturing the status data of opponents matching the target information type, the system can aggregate key game information across accounts without switching screens, significantly reducing the frequency of player operation interruptions and cognitive load, and improving the efficiency of battle decision-making.

[0083] For example, in an eight-player auto chess game, after the system determines that the target information type is lineup information, it can query the status data of the board deployment areas of the other six opponents (other than the opponent currently being played by the current game account) in parallel. From this, it can extract the number of core output pieces and core defense pieces currently deployed by each opponent, their star ratings, and their corresponding cost colors. These extracted results are then summarized into a structured target status data package for subsequent broadcast rendering.

[0084] Optionally, the target status data can include status information such as game economy, lineup composition, equipped items, and win / loss records, which are dynamically determined based on the functional attributes of the target functional area. Optionally, the target status data can be real-time status data from corresponding areas of other game accounts in the second game interface that have the same functional attributes as the target functional area. For example, when a player selects a target functional area with economic attributes in their first game interface, the system can automatically query the interest ball area, level display area, and gold holding area in the corresponding interfaces of other opponents, extracting each opponent's current level, gold reserves, and interest activation status, and uniformly encapsulating this heterogeneous data into target status data for return. As another example, when the target functional area corresponds to equipment attributes, the system can query the equipment slots of other game accounts to obtain the quantity, type, and associated pieces of equipment that each opponent has currently synthesized and not yet synthesized. In this way, by targeting functional areas of the same origin, similar information across accounts can be quickly aggregated without switching display screens, providing accurate data support for subsequent lightweight broadcasts.

[0085] Optionally, to avoid cluttered broadcast windows and a lack of focus due to excessive redundant information in the target status data, after obtaining the raw target status data, further hierarchical filtering and importance sorting can be performed based on the target information type. For example, when the target information type is a lineup attribute, the system can extract all deployed unit information from the status data of other game accounts, but only retain core damage dealers and core damage-absorbing units whose cost level is greater than or equal to a preset threshold, and add a star rating and synergy trigger tag to each retained unit. Furthermore, in some highly competitive battle modes, historical match records and equipment combinations can be combined to add counter-relationship ratings and win rate prediction tags to the target status data, thereby directly generating game situation prompts in subsequent processing. In other words, the target status data can be either unprocessed raw interface mirror data or processed data with decision-aid attributes after intelligent filtering and semantic processing. The specific processing depth can be adaptively configured according to the current game stage and player preferences, thus better balancing lightweight broadcasting with information effectiveness.

[0086] In an optional implementation, obtaining target status data corresponding to other game accounts and target information types includes: querying the status data in the corresponding area of ​​the second game interface of other game accounts that has the same functional attributes as the target functional area of ​​the first game interface. In this way, by leveraging the cross-interface peer-to-peer matching mechanism of functional attributes, the real-time status information of opponents in similar functional positions can be accurately obtained without players switching screens, significantly reducing the burden of cross-screen operations and information memory costs, and effectively improving the efficiency of battle decision-making.

[0087] In one implementation, in response to a defined target functional area—such as the equipment storage bar on the left side of the current player's interface—the system identifies the functional attribute of the functional area as 'equipment attribute', thereby triggering a data query on the second match interface corresponding to other game accounts. Specifically, the background traverses the second match interface of each opponent, automatically retrieves and locates the corresponding area that matches 'equipment attribute', i.e., the equipment bar or loot storage area of ​​each opponent, and then extracts status data from the corresponding area in real time, such as the number of equipment fragments currently held by each opponent, the icon of synthesized equipment, and its wearing status.

[0088] Optionally, the aforementioned corresponding area can be a designated interface module in the second game interface of another game account that is functionally equivalent to the target functional area in the first game interface. For example, when the target functional area is identified as having 'game economy attributes', the corresponding area can be at least one of the interest ball display area, gold coin count area, or level experience bar area in the graphical user interface of another player; when the target functional area is identified as having 'equipment attributes', the corresponding area can be at least one of the equipment synthesis area, component storage area, or equipped item display slot of another player. It should be noted that the above list of corresponding areas is only one example, and this disclosure is not intended to limit it. In different game versions or interface layouts, the presentation form, coordinates, and visual style of the corresponding area may change. As long as the underlying data tags of the area match the functional attributes of the target functional area, it can be included in the query scope. Furthermore, by setting up corresponding functional areas in other players' game interfaces, on the one hand, the complete interface screen capture process can be skipped, and the associated data storage nodes can be directly locked, reducing the amount of data processing; on the other hand, it can also avoid recognition errors caused by differences in interface skins or custom layouts of different players, and improve the accuracy and robustness of cross-account status reading.

[0089] Optionally, the aforementioned identical functional attributes can refer to the category tags assigned to each functional area by the server or client when parsing the interface layout, such as 'Match Economy Attributes', 'Equipment Attributes', 'Team Composition Attributes', or 'Match Win / Loss Attributes'. Among these, Match Economy Attributes typically relate to a set of controls in the interface that display the amount of gold, level progress, or the activation status of interest orbs; Equipment Attributes relate to a set of controls that store or display virtual equipment or equipment pieces; Team Composition Attributes relate to a set of controls used to display the currently deployed virtual characters and their synergies; and Match Win / Loss Attributes relate to a set of controls used to record or display recent match wins and losses. It should be noted that the above description of attribute types is only one example. In actual implementation, other categories such as 'Inventory Capacity Attributes' and 'Health Display Attributes' can be added according to the expanded needs of the gameplay. This disclosure is not intended to limit the scope of functional attributes. By setting unified functional attribute labels for areas with the same observation purpose in the game interfaces of different players, the system does not need to parse the full screen when performing mirror broadcasts. It can quickly index the data of each player based on the same functional attribute. On the one hand, this significantly reduces the scope of status data retrieval, and on the other hand, it ensures a high degree of consistency between the broadcast content and the player's current attention dimension, avoiding interference from irrelevant information.

[0090] In step S150, the target broadcast content generated based on the target status data is output. In this way, by converting the opponent's status data into target broadcast content and outputting it directly, players can quickly obtain key battle information within the game interface without switching screens, significantly reducing operation interruptions and cognitive load, and improving decision-making efficiency.

[0091] In one implementation, after the system acquires the target status data of other game accounts, it generates and outputs corresponding target broadcast content based on this data. For example, if the target functional area is the interest ball area, the generated target broadcast content includes the other players' current level and interest ball activation status, presented in a lightweight form on the current game interface, and automatically disappears after 3 seconds. This allows for the acquisition of key economic information of opponents without interrupting the player's current operation rhythm. Optionally, the aforementioned target broadcast content is used to carry the processed game status information, and its presentation format and duration can be dynamically configured.

[0092] Optionally, the aforementioned target broadcast content can be a structured game information carrier, which can include not only the original status data of other game accounts at the current moment, but also key prompts after analysis and refinement. Considering that players need to quickly grasp the rhythm of the battle and cannot pay attention to secondary information for a long time, as a possible implementation method, the duration of the target broadcast content in the graphical user interface can be set to a fixed duration, such as automatically disappearing after 3 seconds, or being directly overwritten and replaced by subsequent broadcast content when a new broadcast trigger signal is detected, so as to avoid interface obstruction and operation interference caused by information remaining on the screen. It should be noted that the above presentation method of economic data is only an example. The target broadcast content can also be extended to multiple dimensions such as equipment retention, lineup prediction results, and recent win / loss trends. This disclosure is not intended to limit the information dimensions of the target broadcast content. Furthermore, if the current game stage is in the buff selection stage, the target broadcast content can also be configured to display the buff enhancement icons and names selected by other players, thereby helping players to grasp the overall dynamics in real time without switching screens.

[0093] Optionally, the generation logic of the target broadcast content is closely related to the functional attributes of the target functional area, and it can be given differentiated content structures and visual presentation forms according to different functional attributes. In one implementation, when the target functional area is defined as an equipment attribute area, the corresponding target broadcast content can be configured to display the equipment icons and quantities remaining in the equipment areas of other game accounts in a grid view, allowing players to quickly scan the opponent's equipment reserves. As another implementation, when the target functional area is defined as a lineup attribute area, the corresponding target broadcast content can be configured as lineup prediction text or synergy relationship graph output by artificial intelligence combined with the game database for comprehensive calculation, where the core output-type pieces and defensive-type pieces can be marked with differentiated border colors or star ratings. It should be understood that the content structures in the above two implementations can be presented individually or in combination, and this disclosure does not limit this. In addition, to avoid visual clutter on the main interface due to too much broadcast content, a collapse control can also be set in the target broadcast content. After scanning, players can actively close the broadcast window by triggering this control, thereby controlling the density of interface information independently.

[0094] Optionally, the target broadcast content can be contained in various types of interface containers during implementation. These containers can be directly overlaid on the preset anchor point of the first game interface, or they can float near the player character's focus, thereby reducing the player's eye movement costs. In one specific implementation, if multiple target broadcast content output requests exist simultaneously in the current first game interface, the system can assign differentiated display levels and visual channels based on the urgency or triggering sequence of the broadcast information. For example, battle prediction broadcasts can be presented as high-priority half-screen pop-ups, while economic change broadcasts can be presented as low-priority top banners. It should be noted that the above-mentioned interface container forms and layouts are only some examples among many implementation methods. Target broadcast content can also be presented in various forms such as graphical summaries, dynamic icon flashing, or sidebar information streams. This disclosure is not intended to exhaustively limit the output forms of the above-mentioned target broadcast content. Furthermore, to ensure the timeliness of the broadcast information, a timestamp can be added to the target broadcast content. This timestamp can be used to indicate to the player when the data was generated, or the system can automatically trigger content refresh or hide it when data is detected to be expired, thereby maintaining the accuracy and reliability of information presentation in the screen-free state.

[0095] In an optional implementation, after acquiring target status data corresponding to other game accounts and target information types, and before outputting target broadcast content generated based on the target status data, the method further includes: comparing and analyzing the target status data with preset benchmark data to generate game situation prompt information, the target broadcast content including the game situation prompt information. The game situation prompt information may include at least one of resource gap prompts, level advantage prompts, or lineup counter prompts. Thus, by intelligently comparing and analyzing the target status data with preset benchmark data, not only can intuitive game situation prompt information be generated to reduce the information processing burden on players, but also accurate strategic references can be provided based on numerical differences, thereby effectively improving game decision-making efficiency and operational smoothness.

[0096] In one implementation, when a current game account wants to understand its competitive differences with other players, the terminal device acquires target status data (such as gold holdings and level values) of other game accounts in the economic functional area and compares and analyzes it with the current game account's real-time economic data (as preset benchmark data). If the analysis results show that the average gold holdings of other game accounts are higher than the current game account by a preset proportion (e.g., 20%), a resource gap prompt is generated and announced in the target window with a red upward arrow and the specific difference value. Correspondingly, if the level parameters of other game accounts are significantly ahead, a level lead prompt is generated, with the announcement of "Average lead of X levels" in a prominent text. If the analysis model determines that the lineup attributes of other game accounts have a counter relationship with the current game account, a lineup counter prompt is generated, with the prompt including suggested piece types or equipment schemes for adjustment, so that players can quickly obtain strategic guidance without switching screens.

[0097] Optionally, preset benchmark data is used to provide a comparison reference, which may include, but is not limited to, real-time status data of the current game account, historical game statistics, or preset standard thresholds corresponding to each game stage. Optionally, preset benchmark data is a set of data used to provide a reference basis during comparative analysis. Its data source and composition can be flexibly configured according to the actual application scenario. In a non-restrictive example, preset benchmark data can be the real-time status data of the current game account in the corresponding functional area, such as the current game account's own gold holdings, level value, or attribute parameters of the deployed pieces. By comparing the same type of status data of other game accounts with the above real-time status data item by item, the system can quickly calculate the quantified difference value, thereby laying the data foundation for subsequently generating various game situation prompts. Furthermore, preset benchmark data can also be empirical thresholds derived from a large number of historical game statistics, such as reference values ​​considered as economic reserves or level standards at the current game stage. When the status data of other game accounts is higher or lower than this empirical threshold, the system can trigger the corresponding prompt logic. It should be noted that the above description of the preset benchmark data is not an exhaustive list. In actual implementation, the preset benchmark data can be set to the average, highest or lowest value of the status of all or some other game accounts in the current game, excluding the current game account, according to the needs of the specific game mode. This disclosure does not limit this.

[0098] Optionally, considering the objective differences in players' focus at different stages of the game, the preset benchmark data used in the above comparative analysis can be dynamically switched or its weight adjusted according to the current stage of the game. For example, in the early stages of the game, the system can configure the preset benchmark data as the stage standard value corresponding to the level growth curve of each game account. If the level of other game accounts is significantly higher than the stage standard value, a level lead prompt will be generated. In the later stages of the game, the system can switch the preset benchmark data to the current game account's own lineup combat power assessment value. By comparing the predicted lineup combat power of other game accounts with this assessment value, a lineup counter prompt or strength gap prompt will be generated. Furthermore, to avoid visual interference to players due to frequent changes in prompt information caused by single data fluctuations, the comparative analysis process can also introduce a smoothing mechanism. For example, the state data of multiple consecutive time points can be weighted and averaged before being compared with the preset benchmark data. When the difference value continuously exceeds a preset threshold in a stable state, the game situation prompt information will be finally generated and output.

[0099] Optionally, the game situation prompts are generated after intelligent processing of target status data, serving as difference prompts to help the current game account quickly grasp the competitive landscape. Their specific presentation and information dimensions can be flexibly set according to the application scenario. In a non-restrictive example, resource gap prompts can be presented as differences in gold holdings, interest ball activation status, or equipment quantity. For instance, when other game accounts have an average gold holding of more than 20% higher than a preset benchmark, the system generates a text prompt "Enemy Economic Lead" with a highlighted yellow background. Level lead prompts can be represented as current level difference prompts, upgrade progress prompts, or interest ball level activation difference prompts. For instance, when other game accounts have generally reached level 7 while the current game account is still at level 5, the system generates a prominent prompt "Level Lagging by 2 Levels." The team composition counter-picking feature is a strategic prompt generated based on an analytical model that comprehensively assesses the character combinations, equipment setups, and synergy relationships of other game accounts. For example, if the analysis determines that another game account's team composition has an attribute counter to the current game account, the system generates a warning message stating "Enemy team composition counters ours" and may include recommended character types for adjustment. It should be noted that the specific content and trigger thresholds for the resource gap, level advantage, and team composition counter-picking prompts mentioned above are merely examples. In actual implementation, they can be dynamically adjusted according to game balance requirements or player customization settings. This disclosure is not intended to limit their implementation.

[0100] In an optional implementation, the output of target broadcast content generated based on target status data includes: displaying a target window on the first game interface, whereby the target window is used to present the target broadcast content. This achieves localized and lightweight information presentation by directly displaying the target window on the first game interface, avoiding global interface switching and allowing players to quickly obtain game information without interrupting their current operation, thus improving decision-making consistency. In one example, when it is necessary to broadcast the economic status data of other game accounts to the current player, the terminal device directly generates a rounded rectangular target window in the upper right corner of the first game interface screen. This target window is overlaid on the chessboard area with a semi-transparent background, and its contents, from top to bottom, display the level numbers, gold coin amounts, and interest activation indicators of each other game account. When presenting the target broadcast content, the target window is set to display for three seconds and automatically fades away after the time limit, without requiring the player to switch to the current player's first game interface.

[0101] Optionally, the target window is used to display target broadcast content in a local area of ​​the first game interface, and its presentation form can be at least one of the following: a floating window, a sidebar, or a temporary insert.

[0102] Optionally, the display format and duration of the target window can be dynamically configured according to the actual game scenario and operational needs. It can be designed as a semi-transparent floating panel occupying a part of the screen, or as a drawer-style side card that fits the edge of the screen, or even as a temporary information insert that is partially integrated with the first game interface. In one implementation, considering that players need to continuously pay attention to the rhythm of their own chessboard operations, the duration of the target window after it is triggered can be automatically adjusted according to the complexity of the broadcast content. For example, plain text prompts are displayed for two seconds, while report-type content containing multiple columns of data is displayed for four seconds. Alternatively, if the player clicks on the outer area of ​​the window or triggers a new broadcast task during its presentation, a fade-out or shrink animation is immediately executed to free up interface space, thereby effectively avoiding information residue from obstructing the current operation's line of sight, balancing information acquisition efficiency and interface cleanliness.

[0103] Optionally, to avoid visual overlap or interactive conflicts between the target window and the persistent functional controls in the first game interface, the target window can adaptively adjust its position based on the real-time occupancy of each functional area in the current interface during generation. For example, when a player is detected dragging an item in the equipment area, the target window can automatically move to a blank area on the opposite side of the screen, or temporarily reside at the edge of the interface as a thumbnail icon, and then present the full broadcast content with an expansion animation after the player completes the current interaction. Furthermore, the information layout within the target window can also be differentiated according to the type of target broadcast content. For example, economic data can be displayed using a horizontal bar chart to show the gold difference, while lineup data can be displayed using a matrix of avatars to show the core pieces, ensuring that players can grasp key game information within a very short visual dwell time, significantly reducing cognitive load.

[0104] According to one embodiment of the information processing apparatus of this disclosure, a graphical user interface is provided through a terminal device, such as... Figure 2 As shown, the device may include: Display module 201 is used to display the first game interface associated with the current game account through a graphical user interface. The first game interface includes at least one functional area. The first determining module 202 is used to determine a target functional area in at least one functional area in response to an information broadcast trigger command; The second determining module 203 is used to determine the target information type corresponding to the target functional area; The acquisition module 204 is used to acquire target status data corresponding to other game accounts and target information types. Other game accounts are game accounts other than the current game account in the current game. Output module 205 is used to output the target broadcast content generated based on the target status data.

[0105] This helps reduce rendering overhead and interaction redundancy caused by frequent interface switching, improves the efficiency of obtaining status information, reduces the frequency of data interaction between the terminal and the server, and alleviates the processing pressure on the terminal.

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

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

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

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

[0110] 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 3 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.

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

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

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

[0114] 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 of providing a graphical user interface via a terminal device includes: The graphical user interface displays the first game interface associated with the current game account, and the first game interface includes at least one functional area. In response to an information broadcast trigger command, a target functional area is determined in the at least one functional area; Determine the target information type corresponding to the target functional area; Obtain target status data corresponding to the target information type from other game accounts, wherein the other game accounts are game accounts other than the current game account in the current game match; Output the target broadcast content generated based on the target state data.

2. The method according to claim 1, characterized in that, The step of determining a target functional area in response to an information broadcast trigger command includes: In response to a specified operation, control at least one functional area in the first game interface to enter a selectable state; In the selectable state, in response to a selection operation for the at least one functional area, the target functional area is determined.

3. The method according to claim 2, characterized in that, The specified operation is a trigger operation for virtual interactive elements in the first game interface, and the selection operation is a sliding operation from the virtual interactive element to any functional area.

4. The method according to claim 1, characterized in that, The method also includes: Monitor the game status information of the first game interface, and generate the information broadcast trigger command when the game status information meets the preset broadcast conditions.

5. The method according to claim 1, characterized in that, The step of obtaining target status data corresponding to other game accounts and the target information type includes: In the second game interface corresponding to other game accounts, the status data in the corresponding area that has the same functional attributes as the target functional area of ​​the first game interface is retrieved.

6. The method according to claim 1, characterized in that, After obtaining the target status data corresponding to other game accounts and the target information type, and before outputting the target broadcast content generated based on the target status data, the method further includes: The target status data is compared and analyzed with preset benchmark data to generate game situation prompt information; the target broadcast content includes the game situation prompt information.

7. The method according to claim 1, characterized in that, The output, generated based on the target state data, includes the following target broadcast content: A target window is displayed on the first game interface, and the target window is used to present the target broadcast content.

8. The method according to claim 1, characterized in that, Determining the target information type corresponding to the target functional area includes: Based on the functional attributes of the target functional area in the first game interface, determine the type of information to be broadcast corresponding to the functional attributes.

9. The method according to claim 8, characterized in that, The functional attributes include at least one of the following: game economy attributes, equipment attributes, team composition attributes, and game win / loss attributes.

10. The method according to claim 1, characterized in that, The first game interface displays a player list, which includes player identifiers corresponding to the other game accounts; the method further includes: In response to a selection operation for the first player identifier in the player list, the currently displayed first game interface is switched to the second game interface associated with the first player identifier.

11. The method according to claim 1, characterized in that, The first game interface is the game interface where the current game account plays against the second game account among the other game accounts.

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

Images