Game interaction method and device

Abstract

An embodiment of the present disclosure provides a method for game interaction, comprising: obtaining real-time state data from at least two game players; calculating a risk index of each game player based on the real-time state data; in response to the risk index of a target game player satisfying a preset trigger condition, sending an interface display instruction to the target game player to display an interaction interface; receiving a risk decision action from the target game player; calculating a risk settlement result of the target game player according to the risk decision action and the risk index of the target game player; and synchronizing the risk settlement result to the at least two game players to update the risk display information of the game players. Thus, the computing cost caused by distributed processing and the network load caused by repeated transmission are reduced, the rendering resource occupation of the terminal is reduced, and the accuracy of the game state synchronization is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to game interaction methods, apparatus, storage media, and electronic devices. Background Technology

[0002] In real-time multi-user interactive applications, the server typically needs to continuously collect operational status data from each participant and drive global logic changes based on fixed scripts or preset conditions, such as triggering phased events based on fixed countdowns, static area rules, or fixed periods. In related technical solutions, status data for each dimension is often processed by independent business logic modules and presented as scattered elements in the user interface.

[0003] However, under the above processing method, heterogeneous state data is maintained by multiple independent processing links. The server needs to perform a lot of parallel computing and frequent state synchronization operations, which increases the data processing pressure and network transmission load. At the same time, the terminal needs to load and render multiple scattered state prompt elements, and the interface update command interaction is relatively frequent, which causes high terminal computing resource consumption and high rendering overhead, making it difficult to achieve low-latency game state synchronization. Summary of the Invention

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

[0005] According to one aspect of this disclosure, a game interaction method is provided, applied to a server, the method comprising: acquiring real-time status data from the clients of at least two game players; calculating a risk index for each game player based on the real-time status data, the risk index being used to characterize the risk level of the corresponding game player; in response to a target game player's risk index meeting a preset trigger condition, sending an interface display instruction to the target game player's client to cause the client to display an interactive interface, the interactive interface including at least one risk decision option; receiving a risk decision action from the client, the risk decision action being input by the target game player in response to at least one risk decision option included in the interactive interface; calculating the risk status of the target game player based on the risk decision action and the target game player's risk index to obtain a risk settlement result; and synchronizing the risk settlement result to the clients of at least two game players to update the risk display information on the clients.

[0006] According to one aspect of this disclosure, a game interaction method is provided, applied to a terminal of a first player, the method comprising: receiving risk status information from a server, the risk status information including a risk index of the first player; displaying an interactive interface on the terminal, the interactive interface including risk display elements drawn based on the risk index and at least one risk decision option; determining a risk decision action in response to an operation by the first player on at least one risk decision option; sending the risk decision action to the server, so that the server performs settlement based on the risk decision action and the risk status information to obtain a risk settlement result; receiving the risk settlement result from the server; and updating the risk display elements based on the risk settlement result.

[0007] According to one aspect of this disclosure, a game interaction device is provided, comprising: an acquisition module for acquiring real-time status data from the clients of at least two game players; a calculation module for calculating a risk index for each game player based on the real-time status data, the risk index representing the risk level of the corresponding game player; a first response module for sending an interface display instruction to the client of the target game player in response to the target game player's risk index meeting a preset trigger condition, so that the client displays an interactive interface, the interactive interface including at least one risk decision option; a first receiving module for receiving a risk decision action from the client, the risk decision action being input by the target game player in response to at least one risk decision option included in the interactive interface; a settlement module for settling the risk status of the target game player based on the risk decision action and the target game player's risk index, to obtain a risk settlement result; and a synchronization module for synchronizing the risk settlement result to the clients of at least two game players to update the risk display information on the clients.

[0008] According to one aspect of this disclosure, a game interaction device is provided, comprising: a second receiving module for receiving risk status information from a server, the risk status information including a risk index of a first player; a display module for displaying an interactive interface on the device, the interactive interface including risk display elements drawn based on the risk index and at least one risk decision option; a second response module for determining a risk decision action in response to an operation by the first player on at least one risk decision option; a sending module for sending the risk decision action to the server, so that the server performs settlement based on the risk decision action and the risk status information to obtain a risk settlement result; a third receiving module for receiving the risk settlement result from the server; and an updating module for updating the risk display elements based on the risk settlement result.

[0009] According to one aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements any of the above methods.

[0010] According to one aspect of this disclosure, an electronic device is provided, including a processor and a memory, the memory for storing a computer program and the processor for executing the computer program to implement any of the above methods.

[0011] One embodiment of this disclosure provides a game interaction method, comprising: acquiring real-time status data from the clients of at least two game players; calculating a risk index for each game player based on the real-time status data, the risk index representing the risk level of the corresponding game player; in response to a target game player's risk index meeting a preset trigger condition, sending an interface display instruction to the target game player's client to display an interactive interface, the interactive interface including at least one risk decision option; receiving a risk decision action from the client, the risk decision action being input by the target game player for at least one risk decision option included in the interactive interface; calculating the risk status of the target game player based on the risk decision action and the target game player's risk index to obtain a risk settlement result; and synchronizing the risk settlement result to the clients of at least two game players to update the risk display information on the clients. In this way, the server centrally evaluates the real-time status data and synchronizes the settlement result to each client, reducing the computational overhead caused by distributed processing and the network load caused by repeated transmissions, reducing the rendering resource consumption of the terminal, and helping to improve the accuracy of game status synchronization. Attached Figure Description

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

[0013] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this disclosure;

[0014] Figure 2 A flowchart illustrating a method in one exemplary embodiment of this disclosure is shown; Figure 3 A flowchart illustrating a method in another exemplary embodiment of this disclosure is shown; Figure 4 This illustration shows a risk transfer operation interface in one exemplary embodiment of the present disclosure; Figure 5 This illustration shows an audience intervention interface in one exemplary embodiment of the present disclosure; Figure 6A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0015] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0017] It should be noted that the information (including but not limited to user input information, such as information entered by the user into input boxes), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, the service pressure corresponding to operations performed on all code of the current project, and the code development status of the current project), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, the corresponding service pressure, and the code development status involved in this application were all obtained with full authorization.

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

[0019] It should also be noted that the various trigger events disclosed in this manual can be preset, and different trigger events can trigger the execution of different functions.

[0020] The method in one embodiment of this disclosure can run on a terminal device or a server. The terminal device can be a local terminal device. When the method in the embodiment runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and client devices. Figure 1 The figure shows a cloud interaction system architecture diagram provided in this disclosure. As shown, the cloud interaction system may include: a client device 10 and a server 20, wherein the client device 10 can be connected to the server 20 via a network 30.

[0021] In an optional implementation, various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operation mode, the game program's execution and the game screen presentation are separate. The storage and execution of the method provided 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 located 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 screen and other data, returns it to the client device via the network, and finally, the client device decodes and outputs the game screen.

[0022] In an alternative implementation, the terminal device can be a local terminal device. Taking a game as an example, the local terminal device stores the game program and is used to display the game screen. The local terminal device is used to interact with the player through a graphical user interface, that is, conventionally downloading, installing, and running the game program via an electronic device. The local terminal device can provide the graphical user interface to the player in various ways, such as rendering it on the terminal's display screen, or providing it to the player through holographic projection. For example, the local terminal device can include a display screen for displaying the graphical user interface, which includes game screens, and a processor for running the game, generating the graphical user interface, and controlling the display of the graphical user interface on the display screen.

[0023] The game interaction method according to one embodiment of this disclosure is applied to a server, such as... Figure 2 As shown, the method may include: Step S210: Obtain real-time status data from the clients of at least two players in the game; Step S220: Based on real-time status data, calculate the risk index for each player in the game. The risk index is used to characterize the risk level of the corresponding player in the game. Step S230: In response to the target player's risk index meeting a preset trigger condition, a screen display instruction is sent to the target player's client to display an interactive interface, which includes at least one risk decision option. Step S240: Receive a risk decision action from the client. The risk decision action is input by the target player for at least one risk decision option included in the interactive interface. Step S250: Based on the risk decision action and the target player's risk index, calculate the target player's risk status to obtain a risk settlement result; and Step S260: Synchronize the risk settlement results to the clients of at least two players in the game to update the risk display information on the clients.

[0024] According to one embodiment of this disclosure, the server performs centralized evaluation of real-time status data and synchronizes the settlement results to each client, reducing the computational overhead caused by decentralized processing and the network load caused by repeated transmission, reducing the rendering resource consumption of the terminal, and helping to improve the accuracy of game status synchronization.

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

[0026] In step S210, real-time status data is obtained from the clients of at least two players in the match. This real-time collection of multi-dimensional status data from the clients of at least two players provides a synchronous and complete input basis for subsequent risk quantification and mirror game analysis, effectively improving the dynamism and accuracy of risk index assessment. In practical applications, imagine a two-sided tactical competitive match. The first player's client continuously reports the current health, remaining shield, kill streak, and peak damage taken in the last five seconds for their controlled character at a preset frequency. Simultaneously, the second player's client synchronously uploads the distance of their character relative to the safe zone boundary, remaining ammunition, and skill cooldown status. After receiving the aforementioned multi-dimensional status messages, the server performs timestamp alignment and standardized mapping to form real-time status data that can be used for quantized risk pool calculation. The preset frequency can be dynamically adjusted according to network conditions or the stage of the match.

[0027] Optionally, real-time status data may include dynamic parameters of the game across multiple dimensions, such as survival, resources, combat, space, time, and behavior, to provide the raw input basis for the quantumized risk pool. Optionally, the aforementioned real-time status data is not limited to single-dimensional numerical reporting, but can encompass a diverse set of information that can substantially affect the player's current competitive situation. In one implementation, survival-dimensional data may include current health, shield value, abnormal status indicators, and remaining resurrection opportunities; resource-dimensional data may include remaining ammunition, remaining mana, skill cooldown status, and remaining consumable items; combat-dimensional data may include kill streaks, number of times focused fire has occurred, duration of exposure to damage output, and peak damage taken within a preset time window.

[0028] Optionally, "players" refers to the active entities participating in the current competitive match and maintaining an active connection, with their clients acting as the reporting end for status data. Optionally, the aforementioned players can be any two or more users participating in the same player-versus-player match; the specific number is not limited to two, and can be expanded to three-player team battles, five-player lane battles, or mixed fighting formats with multiple factions, depending on the actual battle mode. In one implementation, both sides operate on independent mobile terminals or host devices, with each device acting as a client continuously reporting the real-time status data of its controlled character to the server. Considering the requirements for fairness and data synchronization, the server can prioritize data collection from active clients with network latency below the tolerance threshold and who have completed match confirmation. If a client disconnects or experiences excessive latency, the status data of that player can be marked as abnormal or used in risk calculations with a preset fallback value.

[0029] In optional implementations, real-time status data includes data from one or more of the following dimensions: survival dimension data, including at least one of the following: current health value, shield value, remaining abnormal status or resurrection opportunity value; time dimension data, including at least one of the following: match duration, phase transition node, or overtime status; resource dimension data, including at least one of the following: remaining ammo, remaining mana, skill cooldown status, or remaining consumable items; combat dimension data, including at least one of the following: kill streak, number of times focused fire, duration of output exposure, or peak damage taken within a preset time window; spatial dimension data, including at least one of the following: distance from the safe zone boundary, distance from key enemy targets, or encirclement sector determination result; and behavioral dimension data, including at least one of the following: frequency of proactive charging, continuous firing, aggressive team fight initiation, or chasing down low-health targets. In this way, by collecting multi-dimensional status data encompassing survival, time, resources, combat, space, and behavior, the risk index more comprehensively reflects the player's true situation, thereby improving the accuracy of risk triggering and the sufficiency of information for player decision-making.

[0030] Optionally, survival dimension data is used to collect players' life status and resurrection opportunities in the battle, providing underlying input for the survival pressure assessment of the risk index.

[0031] Optionally, the aforementioned survival dimension data may include one or more of the following: current health, shield value, abnormal status, and remaining resurrection opportunities. The current health value may be expressed as a specific numerical value or a percentage, or it may be combined with the maximum health value to form a normalized characteristic value in risk calculation. The shield value may be an additional protective layer that absorbs damage, such as a temporary shield, energy barrier, or physical armor. Abnormal statuses may cover temporary status indicators that negatively impact a character's actions or output, such as continuous damage, slow, root, blind, or silence. Remaining resurrection opportunities may refer to the character's unused resurrection attempts, buyback eligibility, or available teammate rescue skills in the current match.

[0032] Optionally, time-dimensional data is used to characterize the time progress and stage characteristics of the game, providing underlying input for the time pressure assessment of the risk index. Optionally, the aforementioned time-dimensional data may include one or more of the following: game duration, stage transition nodes, and overtime status. Among them, game duration can be calculated from the start time and accumulated in seconds or minutes to reflect the overall depth of the game's progression; stage transition nodes can correspond to preset key time nodes such as the transition from the early development phase to the mid-game team fight phase, and the transition from the regular time phase to the decisive phase. The system can increase the risk weight when such nodes are approaching to reflect the increased sensitivity of the situation; the overtime status can refer to the additional decisive period that begins after the regular game time has expired, during which the resource refresh rate, death penalty, or mission objective weight may change.

[0033] Optionally, resource dimension data is used to collect the player's available resource balance and skill readiness during the battle, providing underlying input for the resource depletion assessment of the risk index. Optionally, the aforementioned resource dimension data may include one or more of the following: ammunition balance, mana balance, skill cooldown status, and consumable item balance. Among them, ammunition balance can refer to the remaining magazine capacity or total number of bullets for firearms, or the remaining quantity of arrows or throwables; mana balance can be expressed as the remaining percentage or absolute value of the energy bar for magic-type characters; skill cooldown status can include the ratio of the current remaining cooldown time of normal skills, ultimate skills, or equipment active effects to the total cooldown time; consumable item balance can cover the remaining uses of healing potions, teleportation scrolls, scanning devices, or temporary buff items.

[0034] Optionally, the confrontation dimension data is used to collect data on a player's kill streak performance, pressure endured, and output exposure during battles, providing underlying input for assessing the confrontation pressure of the risk index. Optionally, the aforementioned confrontation dimension data may include one or more of the following: kill streak count, number of times a player is focused on, output exposure duration, and peak damage taken within a preset time window. Among them, kill streak count can refer to the number of enemy units a player has defeated without dying consecutively, which the system can use to determine whether the player has entered a high-risk, high-reward aggressive state; number of times a player is focused on can record the number of times a player is simultaneously and effectively attacked by two or more enemy units within a certain time window; output exposure duration can accumulate the length of time a player is within the enemy's line of sight or range while performing an attack action; peak damage taken within a preset time window can be the maximum instantaneous or cumulative value of damage taken by the player within the last N seconds.

[0035] Optionally, spatial dimension data is used to collect information on the player's position and situation in the battle and the degree of environmental threat, providing underlying input for the spatial pressure assessment of the risk index.

[0036] Optionally, the aforementioned spatial dimension data may include one or more of the following: distance to the safe zone boundary, distance to key enemy targets, and encirclement sector determination results. The distance to the safe zone boundary can be the straight-line distance or effective path distance from the player's current coordinates to the edge of the safe zone, often used in tactical competitive games to measure the degree of compression of survival space. The distance to key enemy targets can refer to the spatial interval between enemy defensive towers, base cores, or strategic strongholds. The encirclement sector determination results can be calculated based on the relative positioning angles of enemy units; when multiple enemy units are distributed within a certain angle range around the player, a risk label indicating encirclement is generated.

[0037] Optionally, behavioral dimension data is used to collect the frequency of players' aggressive actions in the game, providing underlying input for the behavioral stress assessment of the risk index.

[0038] Optionally, the aforementioned behavioral dimension data may include one or more of the following: the frequency of proactive charging, continuous firing, aggressive team fight initiation, and low-health pursuit. Proactive charging can refer to a player character's movement from a relatively safe position towards an enemy-controlled area or the location of an enemy unit; continuous firing can record the duration of the player's weapon being in firing mode or the density of bullet discharge; aggressive team fight initiation can refer to a player proactively using control skills or high-damage skills to start a team fight; and low-health pursuit can refer to a player continuing to pursue an enemy unit even when their own health is below a certain threshold.

[0039] In step S220, based on real-time status data, a risk index is calculated for each player. This risk index characterizes the risk level of the corresponding player. By quantifying and integrating multi-dimensional competitive states, both players can perceive risk situations under the same indicator system, thus providing a precise data foundation for subsequent mirror games and dynamic event triggering.

[0040] Optionally, the risk index is used to map multi-dimensional real-time status to a unified quantitative indicator to characterize the current risk level of the players in the game.

[0041] Optionally, the risk index, as a core quantitative indicator in the quantum risk pool, is not limited to a single data source in its numerical generation process. Instead, it can comprehensively consider multiple parameters, including current health and abnormal status in the survival dimension, match duration and stage nodes in the time dimension, remaining ammunition and mana in the resource dimension, peak damage taken and kill streaks in the confrontation dimension, safe zone distance in the spatial dimension, and frequency of aggressive actions in the behavioral dimension. This is taken into account the significant differences in the dimensions and value ranges of the original data across different types of competitive games.

[0042] In an optional implementation, the risk index for each player in a match is calculated, including: normalizing the data of each dimension in the real-time status data to obtain normalized feature values; weighting the normalized feature values ​​based on a preset weight matrix to obtain weighted feature values; and generating a risk index based on the weighted feature values. In this way, by normalizing heterogeneous dimensional data and introducing a configurable weight matrix for weighting, the incomparability between different units of measurement is eliminated, and the risk index can be flexibly adapted to various competitive game categories, effectively improving the accuracy of risk quantification and the applicability of the system.

[0043] Optionally, the above normalization process is used to map real-time status data of different dimensions to a unified numerical range to ensure that risk factors of different dimensions are comparable.

[0044] Optionally, considering that real-time status data of different dimensions have significant differences in their original units and numerical ranges—for example, the health value of the survival dimension may fall in the integer range of 0 to several thousand, while the charge frequency of the behavior dimension may only be counted in single digits—if linear superposition is performed directly, it is very easy for the marginal changes of other dimensions to be masked by the dimensions with larger absolute values.

[0045] Optionally, the normalized feature values ​​mentioned above may include dimensionless values ​​of each dimension after standardization, used as the basic input for subsequent weighted calculations. Optionally, the normalized feature values ​​specifically characterize the relative intensity level of a single-dimensional risk factor after normalization. Their magnitude reflects the relative degree to which the player deviates from the safety benchmark in the current dimension, rather than the original absolute value. As a possible implementation, the system can maintain a set of normalized feature value vectors for each player, corresponding one-to-one with the dimensions of the real-time status data. This vector is refreshed based on the latest data after each background collection cycle, and an incremental change indicator is pushed to the player's client. One objective of this embodiment is to reduce the difficulty of subsequent weight matrix parameter tuning by transforming the original game state into stable, comparable mid-level features, and to provide technical convenience for replacing only the weight configuration while retaining the feature extraction layer during cross-category porting.

[0046] Optionally, the aforementioned weight matrix is ​​used to assign differentiated influence weights to the normalized feature values ​​of each dimension according to different competitive game categories or game stages, so as to flexibly adjust the risk index generation strategy. Optionally, the aforementioned preset weight matrix is ​​not a static set of constants, but a configuration structure that can be dynamically mounted according to game category, game stage, and even version iteration.

[0047] Optionally, in addition to pre-setting fixed weight matrices for different product categories, the system can also introduce an adaptive weight adjustment mechanism based on real-time in-game data to cope with sudden reversals in the battlefield situation.

[0048] Optionally, the above weighted calculation aims to fuse the normalized feature values ​​of each dimension according to the weight matrix to generate weighted feature values ​​that can comprehensively reflect the multi-dimensional risk situation.

[0049] Optionally, the aforementioned weighted calculation can take various forms, such as linear weighted summation, weighted geometric mean, or dynamic weighted fusion based on an attention mechanism. Its input receives a normalized multi-dimensional feature value vector, and its output is one or a set of weighted feature values ​​representing the overall risk level. During the calculation, the weighted feature values ​​can be further decomposed into multiple intermediate components, such as survival risk sub-index, resource risk sub-index, and behavioral risk sub-index, which are then visualized in the risk source label of the mirror game interface. It should be noted that the specific implementation of the aforementioned weighted calculation can be selected based on the server-side computing power budget and the real-time requirements of the game; this disclosure does not limit it to using a specific algorithm.

[0050] Optionally, the aforementioned weighted feature values ​​can be represented as a comprehensive numerical value or numerical vector that integrates multiple risk factors, serving as the direct calculation basis for generating the risk index.

[0051] Optionally, the aforementioned weighted eigenvalues ​​comprehensively carry multi-dimensional risk information after weight matrix optimization. Their values ​​directly reflect the system's overall prediction of the player's likelihood of a deteriorating situation in the next time window. To prevent high-frequency oscillations of the weighted eigenvalues ​​at boundaries from causing repeated state switching, the system can also configure hysteresis intervals. For example, different trigger thresholds can be set when the risk index crosses a first or second threshold, ensuring that the warning is lifted only when the eigenvalue falls below the lower threshold, rather than simply fluctuating between a single critical line. One objective of this embodiment is to improve the stability of the risk state machine and enable players to prepare for the game in advance based on trend predictions by introducing a rate of change and hysteresis mechanism.

[0052] In step S230, in response to the target player's risk index meeting a preset trigger condition, an interface display command is sent to the target player's client to display an interactive interface containing at least one risk decision option. In this way, by linking the risk index with the trigger condition, the risk negotiation portal is automatically invoked at an appropriate time, allowing players to promptly perceive and intervene in risky situations. Simultaneously, the pop-up of the embedded interactive interface does not interrupt the main battle flow, effectively enhancing strategic depth and competitive tension.

[0053] Optionally, the preset trigger conditions are designed to automatically activate the interactive interface to initiate embedded risk negotiation based on rules such as risk index exceeding a threshold, duration, or difference between the two parties. Optionally, the preset trigger conditions can be set to a single threshold exceeding mode or a compound condition superposition mode. In the single threshold exceeding mode, the system can monitor that the risk index is continuously higher than the first risk threshold (e.g., 60%, 70%, or 80%) for a preset first duration (e.g., 8 seconds, 12 seconds, or 15 seconds), thereby determining that the player is in a state of continuous high pressure and triggering the roulette wheel activation; in the compound condition superposition mode, the system can also superimpose the detection of the opponent's risk status, audience activity index, or the high-yield action recently completed by the player on the basis of the above.

[0054] Optionally, the interface is used to present risk decision options as an embedded overlay, allowing players to complete risk negotiation without leaving the main combat scene.

[0055] Optionally, the interactive interface can adopt a semi-transparent devil roulette overlay, or a symmetrical split-screen risk bar combined with a decision panel. This interface can directly overlay the main battle screen, or it can pop up in the center after a short freeze of non-critical interface control elements upon triggering conditions. In one implementation, the visual area of ​​the interactive interface is divided into a left-side risk source label area, a central option decision area, and a right-side opponent risk overview area. The central option decision area displays three candidate entries: accept risk, avoid risk, and delay settlement, using highlighted icons. Considering the cognitive cost of shifting the player's gaze during high-pressure battles, to avoid excessive obstruction of the main battle information by the interactive interface, the interface can use edge fading or background blurring, while retaining the visibility of key battle elements such as the crosshair and minimap. Furthermore, the pop-up duration of this interface can be strictly limited (e.g., 10 or 15 seconds), and vibration and flashing prompts can be provided before the countdown ends.

[0056] Optionally, risk decision options are used to receive players' risk-handling intentions, transforming the abstract risk index into negotiable and settleable game assets. Optionally, risk decision options can include three basic types: accepting risk, avoiding risk, and delaying decision, with further subdivisions under each type. In the accepting risk type, players can maintain their current high burst or high mobility gains by clicking confirm, while retaining the risk index until the next settlement cycle. In the avoiding risk type, players can choose to pay various costs such as health, gold, equipment durability, or skill lockout duration to partially or completely reset the risk index. In the delaying decision type, the system can provide exchange conditions that sacrifice next round's resource refresh, shorten their own safe zone radius, or lock subsequent specific skills, temporarily postponing risk settlement. Considering the differences in resource systems across different game genres, the cost categories and numerical ranges of the above options can be dynamically priced based on the player's current economic reserves, resource balance, and battle stage. In an optional implementation, the preset triggering conditions include at least one of the following: the risk index of the target player exceeds a first risk threshold within a preset first duration; the risk index of the target player instantaneously exceeds a second risk threshold, and the second risk threshold is higher than the first risk threshold; and the difference in risk indices between at least two players exceeds a preset difference threshold. Thus, through the combined design of multi-level triggering conditions and mirror difference determination, not only can precise tiered initiation of risk events be achieved, but also symmetrical game pressure can be created in two-sided competitions, effectively avoiding frequent interruptions or response delays caused by a single threshold.

[0057] Optionally, preset trigger conditions are used to initiate an embedded risk negotiation interaction process when multi-dimensional risk indicators meet specific criteria. Optionally, the preset trigger conditions can be a single criterion taking effect, or multiple criteria taking effect concurrently or in a priority combination; this disclosure is not limited to this. Considering that instantaneous network fluctuations or high-frequency instantaneous player operations may cause occasional fluctuations in the risk index, in order to avoid frequent interruptions to the smoothness of the main game due to brief spikes, the above trigger conditions can be further configured with a confidence window or anti-jitter verification mechanism. Specifically, before determining that the risk index is consistently higher or momentarily exceeded, the system can first check the risk trend direction of the most recent multiple sampled frames, and only when the trend is confirmed to be upward and meets the amplitude requirements will the event be officially triggered.

[0058] Optionally, before the triggering conditions take effect, the system can output tiered warning signals to the client in advance, thus allowing players time to prepare psychologically and operationally. Specifically, when the risk index approaches the first or second risk threshold, a warning color band can be progressively loaded at the edge of the graphical user interface, accompanied by a low-frequency pulse sound effect; when the difference between the risk indices of both sides approaches a preset difference threshold, an imbalance warning can be marked in advance on the mirror game interface to enhance the competitive tension. Furthermore, the parameters of the above triggering conditions are not fixed constants, but can be dynamically adjusted according to the stage of the game, the players' historical style, or the current audience activity. For example, the first risk threshold can be automatically lowered during overtime, or the difference threshold can be appropriately tightened during periods of high-density audience interaction to improve the pace of the game and the entertainment value. This dynamic calibration mechanism can, on the one hand, avoid premature triggering that leads to a compression of the strategy space, and on the other hand, ensure high-frequency triggering at critical moments to maintain the intensity of the game, making the occurrence of risk events more in line with the dual requirements of narrative rhythm and competitive fairness.

[0059] Optionally, the first risk threshold is used to define the baseline boundary for the transformation of a risk accumulation state into an embedded negotiation event. Optionally, the first risk threshold can be set differently based on the game genre, game stage, or player role type, and its numerical configuration is not fixed. In one implementation, for tactical competitive games that emphasize survival, the first risk threshold can be configured as a joint function of health decay and resource scarcity. For example, when a player's health is below 30% and their remaining medicine is less than two units, backward compatibility triggering is allowed even if the overall risk index does not reach the general threshold. In another implementation, for fast-paced fighting games, the first risk threshold can be set lower and respond faster to quickly intervene in risk negotiation when a player is continuously attacked.

[0060] Optionally, a first duration is preset to constrain the minimum observation window length for the risk index to continuously exceed the threshold.

[0061] Optionally, considering the different real-time requirements of different game genres, the preset first duration can be set to a fixed constant, or it can adaptively scale based on the current network latency or server load. As a possible implementation, when the server uses a sliding time window to smooth the risk index, the preset first duration can be matched with the step size and span of the sliding window. For example, the window size can be set to five seconds with a step size of one second, and an event is triggered when the average of three consecutive windows is higher than the first risk threshold. To avoid window interruption due to brief player avoidance behavior, the aforementioned duration can also incorporate a tolerance mechanism, allowing low-value samples within the observation window (not exceeding a preset proportion) without resetting the timer.

[0062] Optionally, a second risk threshold is used to capture instantaneous spikes in the risk index to enable rapid response to emergency consultation events. Optionally, the second risk threshold is typically higher than the first risk threshold, and its function is to identify sudden high-risk outbreaks rather than gradual accumulations.

[0063] Optionally, a preset difference threshold is used to measure the degree of asymmetry in risk status between at least two players in a match. Optionally, the preset difference threshold is set to prevent a one-way snowball effect caused by excessively large differences in risk status between the two players.

[0064] In an optional implementation, audience interaction data is received; semantic parsing is performed on the text data within the interaction data to obtain audience emotion parameters; based on the audience emotion parameters, audience intervention parameters are determined; and if the audience intervention parameters meet preset verification conditions, the result weights of risk decision options are adjusted or a queue of candidate events for risk decision options is triggered based on the audience intervention parameters. In this way, by structuring audience interaction behavior into risk adjustment signals, and adjusting decision weights or triggering candidate events under preset verification conditions, external emotions are deeply embedded in the core game logic, both enhancing the intensity of live streaming interaction and ensuring competitive fairness through a constraint mechanism.

[0065] Optionally, audience interaction data may include bullet screen text, voting results, tipping events, or gift information, used to provide external dynamic input signals to the risk pool. Optionally, audience interaction data can be collected in real time through the live streaming platform's open interface or message subscription protocol. In addition to text-based bullet screens, the data content may also include supplementary information such as user level, fan badges, follow status, or faction affiliation.

[0066] Optionally, semantic parsing can employ natural language processing models to identify the sentiment polarity and behavioral tendencies of the text data, generating audience sentiment parameters that characterize the audience's emotional trajectory. Sentiment polarity distinguishes between positive encouragement and negative mockery, behavioral tendencies distinguish between encouraging aggressive behavior and suggesting conservative approaches, command strength measures the urgency of the text command, and object attribution determines whether the emotion is directed at one's own team, the opponent, or the overall atmosphere. Considering the abundance of industry jargon in game livestreaming contexts, such as "charge," "don't be a coward," "lock in," and "out of mana," as a possible implementation, the system can pre-build a dedicated vocabulary to fine-tune the above model or adapt the embedding layer, thereby improving the accuracy of targeted recognition and avoiding misjudgments of specific game terms by general semantic models. Furthermore, a sliding time window mechanism can be introduced during the parsing process to deduplicate and density-weight high-frequency repeated text within the same window, thus suppressing excessive interference from a single user's spamming behavior on the sentiment parameters.

[0067] Optionally, in addition to the aforementioned deep learning-based automatic semantic parsing method, a combination of rule engines and keyword matching can be used to process text data. For example, aggressive and conservative keyword dictionaries can be pre-set, and audience sentiment parameters can be quickly generated through word frequency statistics and weight accumulation. One objective of this embodiment is to provide a lightweight alternative parsing path, which on the one hand reduces the amount of data processing on low-end servers or edge nodes with limited model inference resources, and on the other hand allows for flexible adjustment of keyword coverage through manual operation and maintenance to adapt to the language habits of different game categories or different cultural regions.

[0068] Optionally, audience intervention parameters can be determined based on a combination of audience sentiment parameters and bullet screen density. Preset verification conditions are used to determine whether the intervention intensity is within the permissible constraint boundaries. Optionally, the audience intervention parameters do not simply map sentiment parameters directly to a risk pool adjustment amount, but rather further combine peak bullet screen density, the intensity of reward events, the concentration of vote distribution, and the coefficient of the current game stage for weighted synthesis to form an intervention intensity value with time-dependent decay characteristics. To avoid external interactions causing destructive impacts on the core competitive fairness, the preset verification conditions can specifically manifest as a combination of multi-dimensional constraints such as an intervention budget cap, a cooldown time window, a permission level threshold, and a cap on the magnitude of influence.

[0069] Optionally, the weights of risk decision options or the queue of triggering candidate events can be adjusted based on audience intervention parameters, aiming to transform audience sentiment into decision offsets or event triggering signals in risk games. Optionally, after receiving validated audience intervention parameters, the execution module of the risk decision system can dynamically shift the initial probability distribution of each risk decision option in the interactive interface based on the aggressive or conservative tendency of these parameters. Specifically, if audience sentiment leans towards aggressiveness, the system can increase the weight of the "accept risk" option while correspondingly reducing the recommended proportion of the "avoid risk" or "delay decision" options; conversely, if sentiment leans towards conservatism, the weight of avoidance options is increased. It should be noted that this weight adjustment is not an absolute rewrite, but rather introduces an external correction factor based on the original risk index calculation, allowing players to retain final decision autonomy, but the expected returns and costs of the options will change accordingly.

[0070] Optionally, to prevent audience groups from maliciously manipulating a particular option through concentrated traffic manipulation, leading to game imbalance, the system can also introduce an anti-cheating verification submodule in the weight adjustment stage. This submodule performs clustering detection and anomaly dilution processing on interactive behaviors originating from the same user level range or the same network address within a short period. Furthermore, when triggering the candidate event queue, the system can set mutual exclusion locks and priority labels for different types of events. For example, when a high-risk mirror event and a low-risk replenishment event coexist in the candidate queue, the event type that best matches the current risk difference between the two sides is prioritized. If the audience intervention parameter happens to be in a fuzzy area between the aggressive and conservative thresholds, it is considered a neutral spectator state. In this case, the system can maintain the current option weight unchanged, only recording the audience activity as a battle report field, without triggering any real-time adjustments. In other words, the final form of audience intervention can be an explicit option weight shift, an implicit candidate event queue, or even a purely record-keeping status label; this disclosure is not limited to these.

[0071] In step S240, a risk decision action is received from the client. This risk decision action is input by the target player in response to at least one risk decision option included in the interactive interface. In this way, by receiving the risk decision actions reported by the client, the server enables players to make proactive choices based on real-time risk states, thereby transforming the traditionally one-way risk into a proactively negotiated game asset, effectively enhancing the strategic depth and psychological game dimension of the game.

[0072] In one implementation, after the embedded interrupt interaction layer briefly freezes the non-critical user interface on the client and pops up the roulette interface, the target player in the game, within a limited countdown, chooses one of three decision branches: accepting risk, paying the price to avoid it, or locking subsequent skills to delay settlement, through any of the following methods: touch screen selection, mouse click confirmation, or gamepad button selection. The client immediately encapsulates the option's identity, trigger timestamp, and the player's current in-game identifier into a risk decision action and reports it to the server.

[0073] Optionally, risk decision actions are used to encapsulate the player's actions in response to risk options into events and report them to the server to trigger settlement.

[0074] Optionally, a risk decision action is a key data unit generated by the client and reported to the server after the player completes a selection on the interactive interface. Its form can be a click confirmation command, a gesture recognition result, a voice command text, or a controller button event, and is not limited to a single human-computer interaction mode. It should be noted that the above examples are merely some of the possibilities, and this disclosure is not intended to limit its form. This risk decision action is typically generated during the display of the roulette or negotiation interface on the game client, and the player can complete the input in various ways before the countdown ends. If the player does not perform any selection operation within the timeout window, the client can automatically report the default option, report an empty value, or maintain the previous state, depending on the preset event configuration strategy. In other words, the risk decision action not only includes explicit commands actively triggered by the player but can also include implicit status markers generated due to timeouts, disconnections, or abnormal interruptions to ensure the integrity of the server-side settlement logic.

[0075] In step S250, the risk status of the target player is settled based on the risk decision action and the risk index of the target player, and the risk settlement result is obtained. In this way, by coupling the risk decision action with the real-time risk index for settlement, the immediate consequences of the player's choice can be quantified and mapped to the competitive status of both sides, effectively supporting the closed-loop feedback of mirror game and enhancing the depth of game strategy and the interpretability of the result.

[0076] Optionally, risk status settlement is used to calculate risk changes, profit changes, and the impact of counterparties based on the type of decision action and the current risk index, in order to migrate the player's real-time status.

[0077] Optionally, considering that risk decision-making actions encompass different categories such as accepting risk, avoiding risk, and delaying decision-making, the settlement logic needs to invoke differentiated settlement rules based on the action identifier. As one possible implementation, when the action identifier corresponds to accepting risk, the settlement module reads the current risk index, maintains or further increases the index to retain the corresponding high-yield state, and records the duration of the kill streak bonus or output boost brought by this choice. When the action identifier corresponds to avoiding risk, the settlement module deducts the risk index according to a preset conversion ratio based on the type and quantity of the paid cost, and simultaneously generates the corresponding resource loss or skill seal state. Furthermore, the settlement process not only updates the target player's internal state but also writes related data to the opponent's end according to the mirror game rules, such as marking the risk value transferred by the player as an external input risk. It should be noted that the conversion ratio and state mapping relationship in the above settlement rules can be dynamically configured according to different game categories or hero characteristics, and this disclosure is not limited to this.

[0078] Optionally, the risk settlement result may include risk change value, duration of gain, opponent's influence marker, and state transition instructions, used to drive client interface updates and data accumulation. Optionally, the risk settlement result, as the output carrier of risk state settlement, can be dynamically organized according to the game stage and decision type.

[0079] In step S260, the risk settlement result is synchronized to the clients of at least two players to update the risk display information on the clients. This ensures that both sides engage in subsequent games based on a consistent risk situation in real time, significantly reducing the probability of imbalance caused by information asymmetry, thereby effectively enhancing the overall strategic depth and competitive fairness of the game.

[0080] Optionally, the above synchronization is used to broadcast the risk settlement results to multiple clients to ensure the consistency and real-time nature of the players' states. Optionally, considering that information lag in competitive matches often leads to distorted gameplay, the above synchronization process can be implemented using a low-latency message channel in an event-driven architecture. This channel not only pushes the numerical changes after risk settlement to the target client but also broadcasts the same event identifier to the opponent's client, enabling both interfaces to align their states within a specified time window. It should be noted that the above synchronization content, in addition to including the increase or decrease in risk value, can also include the risk source category, remaining duration, and externally input risk tags, so that both players can fully understand the composition of the risk transfer.

[0081] Optionally, the aforementioned risk display information may include dynamic risk bars, source tags, and peak markers to visually present the current risk status and its changes to players.

[0082] Optionally, the aforementioned risk display information can be presented directly in the main battle screen in the form of a graphical user interface, or it can be overlaid in the split-screen area of ​​the mirror game interface or in the augmented reality projection space. The risk display information includes at least one or more of the following: a dynamic risk bar, a risk change rate arrow, labels for major risk sources, historical risk peak markers, and a countdown timer for upcoming events. Furthermore, its visual parameters can be dynamically switched according to the risk level.

[0083] According to another embodiment of the present disclosure, the game interaction method is applied to the terminal of the first player in the game, such as... Figure 3 As shown, the method may include: Step S2010: Receive risk status information from the server, the risk status information including the risk index of the first player in the game; Step S2020: Display an interactive interface on the terminal. The interactive interface includes risk display elements drawn based on the risk index and at least one risk decision option. Step S2030: In response to the first player's action on the at least one risk decision option, determine a risk decision action; Step S2040: The risk decision action is sent to the server so that the server can perform settlement based on the risk decision action and the risk status information to obtain the risk settlement result; Step S2050: Receive the risk settlement result from the server; Step S2060: Update the risk display element based on the risk settlement result.

[0084] According to one embodiment of this disclosure, risk elements and decision options are displayed on the terminal based on a real-time risk index, enabling players to actively make risk decisions. This helps reduce instruction redundancy caused by passive triggering and improves the processing efficiency of game interactions. Simultaneously, by providing a front-end interaction entry point for the client, it helps reduce invalid signaling round trips between the server and the terminal, reducing the server's concurrent data processing pressure and the terminal's parsing load.

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

[0086] In step S2010, risk status information is received from the server, including the risk index of the first player in the game. In this way, by receiving the risk status information from the server, the client can transform the multi-dimensional risks in the game into a visualized risk index, providing a real-time data foundation for the player's subsequent risk decisions and interactive gameplay.

[0087] Optionally, the risk status information is generated by the server after quantitatively assessing the player's real-time status, and at least includes the player's risk index. Optionally, the specific content of the risk status information can be flexibly configured according to the actual application scenario. In addition to including the risk index of the first player in the game, it can also carry auxiliary fields such as the risk change rate, the risk source breakdown ratio, and a countdown timer for the upcoming event. In one implementation, when generating this information, the server performs timestamp alignment, deduplication, and noise filtering on the raw data collected from three sources: in-game running data, peripheral interaction data, and live stream and audience data. Then, it calculates the current risk value using a preset normalization algorithm and weight matrix, and encapsulates it into a structured message body before sending it to the client. This message body can be encoded using a structured key-value pair format or a binary serialization format to ensure low-latency transmission and efficient parsing in multiplayer online scenarios. After receiving and parsing the information, the client not only extracts the risk index to update the risk bar, but also triggers amplified hierarchical feedback based on the risk source label. For example, when the breakdown ratio shows that the proportion of resource-related risks exceeds the preset threshold, the client outputs the text prompt "resource endangered" simultaneously, accompanied by a visual presentation of icon flashing and edge coloring.

[0088] Optionally, the risk status information can be distributed using either an active push mode or a passive request mode, with the communication link between the server and the client adaptively switching based on network latency tolerance.

[0089] Optionally, in a two-player mirror game scenario, the risk status information can be further expanded to include the risk index of the opposing player. When generating this information, the server packages the risk data of both players into the same mirror dataset or distributes it through two independent channels to support the client in building a symmetrical risk display component. Considering the needs of psychological game among players, the risk values ​​of the opponent in this information can be anonymized or delayed, for example, only revealing the risk level rather than the precise percentage, or briefly revealing the opponent's main risk source category in a high-risk state to induce the low-risk player to make strategic decisions. Furthermore, the server can also attach historical risk peak markers and risk actionable button prompts to this information, enabling the client to dynamically display the type of roulette event to be triggered and the remaining decision time while rendering the risk bar. It should be understood that the specific constituent fields and synchronization strategies of the risk status information can be designed differently according to the need for balancing competitive fairness and spectator appeal, and this embodiment does not limit this.

[0090] In step S2020, an interactive interface is displayed on the terminal. The interface includes risk display elements drawn based on the risk index and at least one risk decision option. In this way, by mapping the risk index to visible risk display elements and providing risk decision options, not only is risk information visualized and negotiable, but players are also effectively given the ability to interact with risk operations in real time, significantly enhancing the strategic depth and psychological game tension of the game.

[0091] In one implementation, when the first player in a match experiences a rise in risk due to continuous damage taken, the terminal renders a vertical, semi-transparent risk bar in a corner of the main match interface. The height of the warm-colored filled area is positively correlated with the current risk index. Two risk decision options float beside the risk bar: "Accept the risk to maintain killstreak gains" and "Pay health to avoid current accumulated risk." Players can switch between options using touch controls or the gamepad's directional buttons, preview the expected outcome information for each option while hovering, and confirm one option before the countdown expires to complete the risk negotiation interaction. It should be noted that the above-described risk bar shape and option arrangement are only a specific example; in actual implementation, the style can be adjusted according to the terminal screen ratio, game genre, and player preferences.

[0092] Optionally, the risk display element includes visual graphic components representing changes in the risk index, which change their visual attributes according to the value or level of the risk index. Optionally, the risk display element can be in the form of a vertical or horizontal risk bar, a circular progress indicator, a polygonal deformable icon, or a heatmap spot, etc., and this disclosure is not intended to limit its geometric shape. In one specific embodiment, the risk display element is expressed using a vertical gradient bar in a split-screen symmetrical layout, where the overall height of the risk bar corresponds to the range of the risk index, the current risk index is filled with a warm color, and the filling ratio is strictly positively correlated with the real-time risk value, while the remaining part is represented by a cool color to indicate a safety margin. Furthermore, in addition to containing basic information representing the current instantaneous risk value, the risk display element may also include a risk change rate arrow to indicate the rising or falling trend of the risk index within a specified time window. This arrow can be set to a high-saturation flashing state to alert the player that the risk is rapidly deteriorating. In addition, the risk display element can also overlay historical risk peak markers, which record the extreme risk values ​​in this round of the game in the form of temporarily retained scale lines or stars, helping players recall the high-pressure points they have faced. It should be noted that the above combination of visual attributes is only an example. In actual implementation, it can be customized according to the research results of color psychology or the art style of the game world.

[0093] Optionally, considering the differences in visual perception among different players, the risk display element can also adopt a multi-layered redundant coding strategy, that is, simultaneously integrating three dimensions of visual expression—color change, dynamic flashing frequency, and geometric deformation—within the same control. As one possible implementation, when the risk index is in the low-risk range, the risk display element appears as a rounded-edge, cool-colored icon that expands and contracts slowly in a breathing-like manner; when the risk index enters the medium-risk range, the icon's outline gradually sharpens into a warning geometric shape, and the background begins to flash brightly at a medium frequency; when the risk index reaches the high-risk range, the risk display element not only switches to a highly saturated warm color but may also be accompanied by a similar color diffusion effect at the screen edges to create a strong sense of visual oppression.

[0094] Optionally, the risk display elements can be configured for mirrored comparison in two-player or team-based scenarios. This involves synchronously mapping the player's and opponent's risk display elements onto the same visual coordinate system for comparison. In the mirrored game interface described above, the risk bars for both sides are symmetrically arranged along the same baseline, allowing players to intuitively read the risk difference between the two sides and determine whether they are currently in a position of pressure advantage or pressure disadvantage.

[0095] Optionally, risk decision options include risk management actions that players can actively choose. These actions are dynamically generated based on the risk status and can be triggered for confirmation via touch, gesture, or voice.

[0096] Optionally, risk decision options can be a limited set of options automatically generated by the system based on the current risk index and the battle situation, including at least two basic actions: accepting risk and avoiding risk. In one specific implementation, when an embedded risk negotiation event is triggered, a semi-transparent roulette wheel pops up in the center of the interface, displaying three risk decision options: The first option is to accept risk, which allows the player to maintain the current high-risk-reward state and retain high burst or high mobility buffs, but may face a more severe settlement multiplier for subsequent damage taken; the second option is to pay a price to avoid risk, which allows the player to pay a specific amount of health, gold, or skill ban time to reduce the risk index to a safe range; the third option is to delay settlement or exchange conditions, which allows the player to exchange the right to use subsequent skills or sacrifice the next round's resource refresh opportunity for a temporary postponement of the current risk settlement. The text descriptions and icon forms of the above options can be packaged according to the game's world view, for example, presented in the visual form of a contract, tarot cards, or energy capsules, but their underlying logic all points to a negotiable game between risk and reward. It should be noted that the parallel display of the above three options is only an example. In actual implementation, the system can also push the preferred options that a specific player frequently selects as the default highlight based on historical game data.

[0097] Optionally, considering that players may accidentally select an option or hesitate to make a decision under high pressure, the interactive confirmation mechanism for risk decision options can be designed as a tiered trigger structure with a preview buffer. As one possible implementation, when a player hovers the pointer or focuses their gaze on a risk decision option, the system first displays a projected settlement preview panel next to that option. This panel dynamically displays the projected risk index change, resource consumption value, and related impacts on the player's side after selecting the option, allowing the player to make a secondary judgment before final confirmation. Furthermore, to prevent players from accidentally selecting unintended options under countdown pressure, the system can incorporate anti-accidental-touch logic. For example, upon receiving the player's initial confirmation command, the system doesn't immediately take effect but instead highlights the option's border and initiates a brief secondary confirmation window. If the player doesn't issue a cancellation command during this period, the risk decision is officially confirmed when the window ends.

[0098] In an optional implementation, the risk status information also includes the risk index of the opposing player; the risk display elements include the player's own risk bar and the opponent's risk bar, which are synchronously mapped to the same visual coordinate system. In this way, by symmetrically mapping the risk indices of both sides to the same visual coordinate system, players can intuitively perceive the relative risk situation, forming an explicit psychological game space, effectively improving the depth of the confrontation strategy and the competitive balance.

[0099] Optionally, the opponent's risk index represents the opponent's real-time risk status, which is dynamically calculated and distributed by the server based on multi-dimensional factors.

[0100] Optionally, the risk index for opposing players can be a continuous value or a discrete level calculated by the server using a normalized weighted model after real-time collection of data on opposing players' health percentage, skill cooldown remaining, spatial exposure duration, and audience sentiment fluctuations. This index can be limited to a single dimension of survival pressure, or it can further incorporate composite parameters such as resource scarcity, recent damage peaks, and relative distance to the safe zone boundary in the spatial dimension. To avoid data fluctuations caused by network jitter interfering with player judgment, the server can apply a sliding time window smoothing or exponential filtering to the risk index and interpolate it on the local client at a fixed synchronization frequency.

[0101] Optionally, the risk index of the opposing player can be anonymized or layered when transmitted to the first player's terminal to avoid overly exposing the opponent's core tactical details. For example, the server can only send the risk level (such as medium risk, high risk) instead of the precise value, or retain the relative length ratio on the risk bar while hiding the specific percentage. Furthermore, when the risk difference between the first player and the opposing player exceeds a preset mirroring threshold, the system can also generate a dynamic connection identifier or difference prompt between the two risk bars to enhance the perception of the risk gap.

[0102] Optionally, the player's own risk bar is used to graphically represent the risk index of the first player in the game, and its visual parameters are dynamically adjusted as the risk value changes.

[0103] Optionally, the player's risk bar can be presented in a designated area of ​​the interactive interface in the form of a horizontal progress bar, a circular dashboard, or a vertical bar chart. Its fill length, color saturation, or texture density are positively correlated with the risk index of the first player in the game. In addition to the main progress area, the risk bar can also display auxiliary visual elements such as arrows indicating the rate of risk change, historical peak markers, or labels indicating the main sources of risk. For example, when the risk index rises rapidly in a short period of time, an upward dynamic arrow can appear at the end of the risk bar, accompanied by a bright flashing edge; when the main source of risk is resource scarcity, a grid texture can be superimposed on the surface of the risk bar for distinction. The position of the risk bar can be adjusted according to different game genres. In landscape shooting games, it can be placed in the main information display area in the center of the bottom of the screen, while in portrait card battles, it can float above the player's character portrait. This multi-dimensional visual encoding allows players to instantly read their own risk status and its evolution trend without interrupting the main operation flow.

[0104] Optionally, considering the distribution of players' visual focus during high-speed combat, the color scheme of the player's risk bar can gradually transition from cool tones in normal conditions to warm or warning tones in high-risk situations, using color intuition to reduce cognitive load. To avoid excessive visual interference in low-risk phases, the risk bar can be displayed silently in a semi-transparent or shrunken form in normal conditions, gradually increasing its opacity and size only after entering a risk accumulation state. Furthermore, when the risk index of the first player in a match reaches a threshold warning state, the risk bar can also trigger secondary feedback, such as generating a breathing light effect around its outer contour or a pulse fluctuation to guide the player's attention. If the player's risk bar and the opponent's risk bar visually overlap in the same local interface, the system can automatically adjust their relative spacing or use different hues to distinguish them; this disclosure does not limit their specific arrangement.

[0105] Optionally, the opponent risk bar is used to graphically represent the risk index of the opponent player, and its visual presentation maintains a symmetrical mapping relationship with the player's own risk bar.

[0106] Optionally, the opponent's risk bar can maintain a symmetrical aspect ratio and scale with the player's risk bar in terms of visual form. However, its color scheme can use complementary colors that are clearly distinguishable from the player's risk bar, such as a blue-green gradient for the player and an orange-red for the opponent, to reduce visual confusion when players compare risks. In addition to representing the current value of the opponent's risk index, this risk bar can further display limited advantage hints or suggestive game information. For example, when the opponent is under pressure, a text label or icon for the "Opponent Under Pressure" category can briefly appear next to their risk bar. To avoid over-revealing the opponent's status and disrupting the suspense of the game, the update of the opponent's risk bar can have a controlled delay or be blurred, reflecting a snapshot of the risk from a few seconds ago rather than an absolute real-time value. This design allows the player with lower risk, even if they have an informational advantage, to potentially increase their own risk if they become overly aggressive, thus maintaining a dynamic balance in the competition.

[0107] Optionally, the opponent's risk bar can incorporate additional strategic functions in specific scenarios. For example, after the Devil's Roulette event is triggered, the filled area of ​​the opponent's risk bar can be partially locked or marked as a transfer zone to visually represent the flow and magnitude of risk transfer. This risk bar can not only display the opponent's overall risk index but also, after a player performs a specific scouting action, further break down and display the main components of the opponent's risk, such as 40% survival risk and 35% resource risk. It should be understood that the visibility of the opponent's risk bar can be dynamically adjusted based on the game stage or player skill status. For example, in some stealth-based games, the opponent's risk bar may only be fully displayed while scouting skills are active. Furthermore, if an opponent chooses to pay a price to avoid risk, their risk bar can briefly sink with an animation and release specific visual particle effects, providing both players with clear feedback on their risk decision.

[0108] Optionally, a shared visual coordinate system provides a unified visual reference for both players' risk bars, allowing players to compare risks and make strategic decisions based on the same metric. Optionally, this shared visual coordinate system can be a mirrored layout framework constructed based on the horizontal center line of the screen, where the player's and opponent's risk bars are equidistantly distributed around this axis of symmetry and share a unified set of percentage scales or risk level segmentation markers. Considering that players need to make risk comparisons instantly during intense combat rather than reading two isolated numbers separately, the background layer of this coordinate system can contain fine grid lines or node markers to allow players to accurately compare the fill lengths of both players' risk bars.

[0109] Optionally, in addition to displaying static risk bars, this visual coordinate system can dynamically map the rate of risk change, the composition of risk sources, and countdown information for upcoming events. For example, when the risk difference between the two players exceeds a mirror threshold, a dynamic beam of light or tension line connecting their risk bars can appear in the center of the coordinate system, with its color intensity positively correlated with the magnitude of the difference. Considering the differences in visual perception among different players, the scale of this coordinate system can be adaptively scaled, extending horizontally on widescreen devices to highlight the contrast, while switching to a compact, overlapping contrast mode on smaller mobile devices.

[0110] In an optional implementation, multimodal feedback signals are received from the server, which are generated based on a risk index; these signals are then output on the terminal. In this way, by transforming abstract risk values ​​into multi-channel sensory feedback, players can perceive the urgency of the battle situation in real time and receive multi-dimensional advance warnings, effectively enhancing the immersive experience of risk interaction and the space for strategic prediction.

[0111] Optionally, multimodal feedback signals include visual, audio, or tactile feedback, used to convert the risk index into multi-channel sensory cues. Optionally, these multimodal feedback signals can manifest as visual interface color shifts, high-saturation warning colors at screen edges, or rhythmic flashing of specific icons; auditory signals such as accelerated background music rhythms, increased ambient noise levels, or pulsed sound effects simulating heartbeat frequencies; and tactile signals such as increased controller vibration frequency, regional vibration variations, or adaptive trigger damping changes. Considering the differences in hardware configurations across different terminals, the system can simultaneously output signals from all sensory channels to maximize the sense of risk pressure, or selectively activate certain channels based on player preferences or device capabilities. When the risk index is in an accumulation phase, the intensity of the multimodal feedback can establish a positive correlation with the risk value. For example, volume, color saturation, and vibration amplitude can be adjusted using linear or exponential curves. This allows for gradual pressure instead of abrupt single-point alarms without interrupting the main game loop, enabling players to receive perceptible warning signals early in the risk escalation phase and prepare for the game accordingly.

[0112] In optional implementations, the multimodal feedback signals include one or more of the following: visual feedback, including at least one of the following: icon flashing, risk bar color change, screen edge tinting, or interactive interface overlay display; tactile feedback, including vibration feedback; audio feedback, including sound effect enhancement; and control feedback, including crosshair disturbance. In this way, by mapping the risk index to multimodal feedback signals across visual, tactile, audio, and control dimensions, players can instantly perceive changes in the risk situation without shifting their primary gaze, effectively improving the efficiency of risk information transmission and enhancing the immersion in the game.

[0113] In one implementation, when the risk index of the first player in a match exceeds the intermediate threshold due to continuous damage and resource depletion, the terminal simultaneously activates four types of modal feedback to construct a progressive pressure field. Specifically, in the visual dimension, the strategic resource icons at the edge of the interface enter a high-frequency flashing state, the player's vertical risk bar gradually changes from cool blue to orange-red along the color wheel, and the edges of the screen are colored with a blood-red hue through post-processing. At the same time, a semi-transparent interactive interface overlay pops up at the top center to indicate that resources are in danger. In the tactile dimension, the associated controller outputs a low-frequency continuous vibration and switches to a high-frequency pulse the moment the risk increases, allowing the player to directly receive the status warning through palm tactile feedback. In the audio dimension, the background music beat (BPM) rises synchronously with the low-frequency pulse, and a metallic friction sound effect is layered on the audio track to create acoustic pressure. In the control dimension, the shooting crosshair undergoes periodic micro-shaking with the risk value as a weight, and the dispersion radius expands as the index increases, directly linking operational instability to the pressure of the battle. Furthermore, the triggering timing of the aforementioned multiple types of signals can be aligned and calibrated by the system according to the current local frame rate to avoid cognitive interference caused by sensory channel asynchrony.

[0114] Optionally, visual feedback is used to convey to the player the current level of the risk index and its evolution trend through the state changes of at least one visual element in the graphical user interface.

[0115] Optionally, visual feedback can take various forms, such as icon flashing, risk bar color shifting, screen edge tinting, or interactive interface overlay display. Among these, icon flashing can be applied to health, armor, or specific skill icons, and its flashing frequency is positively correlated with the current risk value.

[0116] Optionally, to avoid the simultaneous appearance of multiple visual signals that could distract players or obscure key battlefield information, the system can establish a visual feedback priority queue and mutual exclusion rules. For example, when the interactive interface overlay is displayed, the screen edge shading can pause its erosion towards the center and reduce saturation to reserve sufficient visual channels for players to read decision options within the overlay; similarly, when a player is in a precise aiming action and crosshair disturbance is activated, icon flashing can be paused or switched to static highlighting to prevent high-frequency flashing from inducing visual fatigue and interfering with crosshair positioning.

[0117] Optionally, haptic feedback aims to convert the risk index into a physical vibration waveform, delivering a status warning to the player through a haptic output device associated with the terminal, which can be perceived without requiring visual input. Optionally, haptic feedback can be specifically implemented as vibration feedback, with vibration modes that can be configured differently based on the magnitude of the risk index, its rate of change, and the current stage of the game.

[0118] Optionally, audio feedback is used to dynamically adjust or superimpose output sound effects based on the risk index, in order to deliver acoustic cues to players through the auditory channel that match the current pressure of the battle. Optionally, audio feedback can be specifically manifested as sound effect enhancement, the enhancement of which can cover multiple dimensions such as the rhythm density of background music, the mixing intensity of low-frequency pulses, and the layering of environmental noise.

[0119] Optionally, control feedback is used to allow players to directly experience the real-time impact of the risk index on the precision of character control by changing the response characteristics of the terminal input device.

[0120] Optionally, the control feedback can be specifically manifested as crosshair perturbation, the amplitude, frequency, and direction of which can be jointly calculated based on the current risk index and the type of weapon used. As one possible implementation, the crosshair perturbation is not a simple random drift, but rather employs a directional offset strategy designed based on the risk source category. For example, when survival-related risks dominate, the crosshair can simulate the physiological tremors of a character's injured arm, exhibiting low-frequency, large-amplitude vertical swings; when resource-related risks are too high, the crosshair can simulate weapon instability caused by ammunition shortages, manifesting as continuous micro-jumps in the horizontal direction.

[0121] In an optional implementation, risk transfer authorization information is received from the server; a risk transfer operation interface is displayed on the terminal, containing at least one risk transfer operation option, including one or more of the following: risk transfer option, skill theft option, risk mirroring option, and cost rewriting option. In this way, through the dynamic redistribution of risk status and temporary interaction of skill resources among players, not only is the strategic dimension of competitive gaming expanded, but also the one-way risk snowball effect is effectively avoided, maintaining the fairness and suspense of two-way competition.

[0122] For example, in one implementation, after the first player wins in an embedded risk decision event, the server determines that they meet the risk transfer authorization conditions and then pushes risk transfer authorization information to the player's mobile terminal. In response, the terminal displays a risk transfer operation interface overlaid on the main battle interface. This interface is presented as a semi-transparent floating window in the lower half of the screen, containing options for risk transfer, skill theft, risk mirroring, and cost rewriting. Players select the risk mirroring option via touch, and the system temporarily binds the risk change rates of both players. Subsequent aggressive actions by either side will simultaneously increase the risk index of both players, thus creating a psychological game of mutual restraint within a localized period. Figure 4The interface shown describes a risk transfer operation interface, which includes a mirror risk comparison bar (72% for your side vs 55% for the opponent), an FPS battle screen area, and bottom operation buttons (accept risk / pay resources to avoid / delay settlement / risk transfer / skill theft / risk mirroring).

[0123] Optionally, the risk transfer authorization information represents a permission signal from the server allowing players to enter the risk transfer operation interface, and its triggering is related to the game situation and event settlement results. Optionally, the issuance of risk transfer authorization information cannot occur at any time, but depends on the server's multi-dimensional comprehensive judgment of the current game state. One purpose of this embodiment is to ensure the scarcity of risk transfer as a limited reward mechanism through a tiered verification mechanism, and to prevent invalid authorizations after the audience's intervention and budget exhaustion. This authorization information can be encapsulated at the transport layer into a data packet containing an authorization type code, an effective countdown timer, and an applicable scenario identifier. After receiving it, the terminal generates a corresponding entry in the interactive interface accordingly.

[0124] Optionally, the risk transfer operation interface is used to carry the interactive presentation and status feedback of risk transfer operation options. Its display level can be higher than the main combat interface, and it can be configured as a semi-transparent mask or a side floating window.

[0125] Optionally, the risk transfer interface is typically designed as an embedded interruption layer. Its purpose is to provide players with a risk reallocation decision-making interface within a limited time window without completely disrupting the main game. This interface can be displayed directly in the central area of ​​the graphical user interface, or it can pop up from the edge of the screen as a sliding floating window after the first trigger condition is met. In addition to a basic list of risk transfer options, this interface can also display the remaining valid duration of the current authorization, miniature mirrored bars of the current risk indices for both players, and preview labels showing the effects of each option after execution.

[0126] Optionally, the risk transfer operation options are used to receive selection instructions from players regarding risk redistribution or adversarial resource interaction. These options may include at least some or all of the following: risk transfer, skill theft, risk mirroring, and cost rewriting. Optionally, the risk transfer operation options, as a higher-level general concept, aim to provide players with multiple asymmetric risk management paths, enabling them to flexibly choose the settlement logic based on the real-time battle situation. In addition to basic actions such as risk transfer, skill theft, risk mirroring, and cost rewriting, this set of options may also include other extended actions, such as temporarily unlocked collaborative risk-sharing options or one-time resource exchange options.

[0127] Optionally, the risk transfer option receives instructions to transfer a preset proportion of the current player's risk value to the opposing player. The transferred risk is marked as an externally input risk on the opposing side and participates in subsequent settlement. Optionally, the risk transfer option is a lower-level implementation with direct adversarial characteristics within the risk transfer operation options. Its execution logic aims to overcome the limitation that risk is usually borne unilaterally by the player in a competitive scenario lacking a risk transfer channel. After selecting this option, the system reads the transferable proportion in the current player's risk pool. This proportion can be a fixed preset value, or it can be calculated based on the risk difference between the two players, or it can be dynamically adjusted based on audience voting preferences.

[0128] Optionally, the Skill Steal option is used to receive instructions to temporarily invoke an opponent's ultimate or key skill. During the invocation, the skill is available to the current player in a limited-time borrowed or equivalent replacement form. Optionally, the Skill Steal option allows the winning side to temporarily invoke an opponent's ultimate or key skill for a limited time. This invocation is not a permanent steal, but rather generates a temporary skill slot in the form of a mirror copy or equivalent replacement.

[0129] Optionally, the Risk Mirroring option is used to receive instructions to temporarily bind the risk change rate of both players in the game. During the binding period, aggressive confrontational behavior by either side will simultaneously increase the risk index of both players.

[0130] Optionally, the core function of the risk mirroring option is to bind the rates of change of the originally independently evolving dual risk pools within a specific time window, forming a strong mutual restraint relationship. During the period when this option is in effect, the system monitors in real time the frequency of aggressive behaviors, damage-to-output ratio, and positional advance of both parties, and maps these behaviors, which originally only affected the risk index of one party, into the risk increment calculation of both parties.

[0131] Optionally, the cost rewrite option is used to receive instructions that map the risk avoidance cost portion currently paid by the player to the opponent's subsequent resource limits. This mapping applies to the opponent's skill cooldown or resource decay logic.

[0132] Optionally, the cost reversal option aims to partially convert the costs incurred by players to reduce risk, such as health, gold, or skill ban duration, into the opponent's future operational burden. When this option is selected, the system extracts the type and amount of costs paid in the most recent round of risk avoidance settlement and generates negative statuses on the opponent's side according to preset mapping rules.

[0133] In an optional implementation, audience intervention parameters are received from the server, generated based on audience interaction data. Audience intervention indicators are displayed on the terminal's interface, indicating changes in the weight of at least one risk decision option. By quantifying the interactive behavior of live stream viewers into perceptible intervention parameters and presenting them in real-time on the terminal interface, players can directly perceive the biases of external viewers during risk decision-making, effectively enhancing the interactive immersion and strategic transparency of the live stream, and expanding the dimensions of audience involvement in competitive strategies.

[0134] In one implementation, when the first player enters the embedded risk event interface triggered by a high-risk state, their terminal receives and displays a fan-shaped audience intervention indicator between the two decision controls: "Accept Risk" and "Avoid Risk." This indicator uses red and blue bars to represent the proportion of viewers supporting a radical stance and those supporting a conservative stance, respectively. It also displays a percentage indicating how much the weight of the "Accept Risk" option has been increased by 15% due to audience voting. Players can then weigh whether to follow audience trends or act against them to gain higher implicit benefits. Furthermore, the indicator's transparency is positively correlated with the density of comments, thus visually conveying the intensity of external intervention without obscuring the main operation area. Figure 5 The interface shown is a viewer intervention interface, which details the game popularity (8.9 / 10), barrage sentiment (aggressive 63%), intervention budget of 2 times this round, and 11 seconds of cooldown remaining; voting options (Vote A: Increase the probability of live bullets by 48%, Vote B: Increase the cost of avoidance by 31%, Vote C: Enable risk mirror by 21%), super barrage (candidate event triggered: barrage roulette) / gift bonus (the streamer faction gains 1 risk delay qualification); and interactive controls at the bottom of the interface for participating in voting, sending barrages, and viewing the impact description.

[0135] Optionally, audience intervention parameters are used to transform audience interaction behavior into moderating variables for risk decision-making. These parameters may include influencing factors such as aggressive coefficients and conservative coefficients, and are processed by the server before being distributed.

[0136] Optionally, the aforementioned audience intervention parameters can be generated by the server based on structured data from multiple dimensions, including real-time bullet screen text, voting events, gift-giving behavior, and peak platform interaction. Considering the high randomness and contagiousness of audience behavior in live streaming scenarios, to prevent external intervention from directly undermining the fairness of the competition, these parameters can be further superimposed with boundary rules such as intervention budget constraints, cooldown period verification, and single-influence limits during the generation process. This ensures that they serve only as a reference for adjusting the weight of risk decision options rather than a determining factor in the outcome. In other words, the audience intervention parameters are not a simple translation of the original audience emotions, but rather a compliant control signal that has been filtered, smoothed, and normalized by the fairness verification module. Its purpose is to provide players with a playable external variable while maintaining the strategic subjectivity of the game's outcome.

[0137] Optionally, the manifestation and target of audience intervention parameters are not limited to a single dimension. They can be reflected in the weight shift of the probability of a certain risk decision option, or in temporarily adding or blocking specific candidate actions in the roulette interface. They can even map emotional polarity to the intensity of the opponent's mirror perception feedback. For example, when aggressive keywords such as "charge" and "don't back down" appear frequently in the comments, the audience intervention parameters can correspondingly increase the expected benefit weight of the "accept risk" option; while when conservative keywords such as "stay calm" and "don't go in" appear frequently, the weight of the "avoid risk" option is increased or the cost required to be paid is reduced.

[0138] Optionally, audience interaction data can encompass bullet comments, votes, donations, or platform interaction segments, serving as input sources for generating audience intervention parameters. Optionally, the aforementioned audience interaction data can at least obtain raw information streams such as real-time bullet comment text, user-sent timestamps, voting options and corresponding quantities, gift or donation event types and their intensity, and platform-side interaction peak segments through the live streaming platform's open interface.

[0139] Optionally, in addition to text-based bullet comments, audience interaction data can also include non-textual interaction signals, such as the frequency of like combos, the density of emoji storms, the count of virtual gift combos, or sudden changes in the number of viewers in the live stream. This disclosure is not intended to limit these. Considering that different forms of interaction affect the risk pool differently, the system can assign a higher single-trigger weight to reward events, but with strict cooldown and cap rules; while for high-frequency, low-density ordinary bullet comments, a trend coefficient is generated by aggregation statistics within a sliding time window. In this way, on the one hand, large-amount reward events can avoid excessive impact on risk decisions, and on the other hand, the continuous accumulation of bullet comment density can reflect the overall emotional trend of the audience, thus providing players with a more robust reference for external intervention.

[0140] Optionally, audience intervention indicators are used to visually represent intervention parameters on the interactive interface, prompting players to indicate changes in the weight of risk decision options.

[0141] Optionally, the aforementioned audience intervention indicator can be directly embedded in the vicinity of the risk decision option in the form of a combination of text and graphics. For example, dynamic color blocks, percentage values, or fan-shaped scale bars can be displayed above or to the side of each option button to represent the weight gain or reduction of the option due to audience intervention. The intensity of the indicator can be dynamically switched under different risk levels or audience activity levels: when the audience intervention parameter is in the neutral range, the indicator is displayed permanently as a light gray static icon; when the parameter enters the significant influence range, the indicator can switch to high-frequency flashing or breathing light animation, accompanied by warm color filling to attract the player's attention. Optionally, the visual form of the audience intervention indicator is not limited to flat numbers or color bars. It can also be expressed as a halo outline around the option control, a dynamic flag icon with a faction affiliation color, or a three-dimensional columnar indicator projected onto a real table in AR augmented reality form, etc. This disclosure does not limit this.

[0142] Optionally, the weight changes are used to characterize the probability or payoff adjustment of risk decision options under audience intervention, and can be dynamically determined based on audience emotional polarity and interaction intensity. Optionally, the aforementioned weight changes can be specifically reflected in various numerical dimensions such as the probability shift of the selected risk decision option, the correction of the expected payoff multiple, or the dynamic discount of the required cost, and this disclosure is not intended to limit them.

[0143] Optionally, the weight changes can apply to a single risk decision option, a combined strategy path consisting of multiple options, or even, when both players simultaneously enter a mirror game event, differentiate the audience intervention parameters applied to the option pools of both sides, forming an asymmetric game structure. If the audience intervention parameters are in an extreme range that may lead to an imbalance in the weight of a certain option, the system can automatically trigger a fallback correction mechanism. This could include setting an upper limit for single-item weight changes, introducing a coupling attenuation coefficient with the player's local risk index, or temporarily freezing the audience intervention effect when the weight difference between the two sides is too large, in order to maintain competitive balance. Furthermore, this weight change can also be correlated with historical game data. If a player has repeatedly chosen to "accept risk" and failed in historical games due to the audience pushing up the aggressive weight, the system can appropriately reduce the impact of the aggressive coefficient on the player's option weight in subsequent games under the same scenario, forming a personalized intervention calibration strategy.

[0144] In optional implementations, the interactive interface can be displayed in an augmented reality (AR) format. In this AR format, the interactive interface includes: acquiring images of the real environment via the terminal's camera; identifying planar areas in the real environment; and projecting risk display elements onto the planar areas. By mapping virtual risk information to a real-world scene, not only is the spatial perception dimension of risk status expanded, but players can also intuitively grasp the risk distribution in the real environment, effectively enhancing the sense of presence during the game and the intuitiveness of tactical decisions.

[0145] Optionally, augmented reality display formats aim to map the risk interaction interface into the real space to present risk warnings through a blend of virtual and real methods.

[0146] Optionally, the augmented reality display can be a specific form of risk visualization, which at least involves overlaying virtual objects such as risk display elements, risk hotspot markers, risk transfer paths, and wheel trigger markers onto a real-world image captured by a camera. Considering the differences in processing power and spatial positioning accuracy of mobile terminals, the above mapping process can be implemented using the plane detection and feature point tracking interfaces provided by the native augmented reality software development kit of the mobile operating system.

[0147] Optionally, risk display element projection is used to overlay virtual risk markers onto a real-world planar area, generating a virtual-real blended risk warning in the player's field of vision.

[0148] Optionally, the rendering pipeline for the risk display element projection can employ a physically based virtual-real fusion scheme, where the lighting direction and shadow projection parameters of the virtual content can be matched in real time based on the direction of the main light source estimated from the real environment image. In one implementation, if the planar area is a horizontal desktop, the risk bar can be rendered as a semi-transparent columnar object vertically suspended above the plane, with its bottom shadow projected onto the desktop according to the direction of ambient light, thereby enhancing the spatial consistency between the virtual object and the real environment.

[0149] Optionally, when multiple risk display elements to be projected on the same plane area have spatial overlap or depth conflict, the system can introduce hierarchical management and dynamic obstacle avoidance mechanisms to intelligently adjust the arrangement of the above elements.

[0150] In optional implementations, the interactive interface can be displayed in a virtual reality (VR) format. In the VR format, the interactive interface includes: displaying a risk negotiation scenario on the terminal when the first player's risk index reaches a preset threshold; and receiving input from the first player in the risk negotiation scenario, including gaze input, gesture input, controller pointing input, or voice input. Based on the input, the corresponding decision-making command is used as the risk decision action. Thus, by leveraging the VR risk negotiation scenario and multimodal natural input, players can make risk decisions through spatial intuition without leaving the main game, significantly enhancing the immersive experience and ease of operation in high-pressure gaming.

[0151] In one implementation, the first player in a two-player match wears a virtual reality headset. When the system determines that their risk index exceeds a preset threshold, a risk negotiation scene is displayed above and in front of their field of vision, while maintaining the continuous settlement of the main match in the background. This scene displays several risk decision options in the form of a three-dimensional floating window. Players can complete the gaze operation by staring at an option for three seconds, or by waving the controller to the left, or by using the controller to point at the target option and press the trigger, or by directly saying the name of the corresponding option. The system recognizes the above inputs in real time and maps them into corresponding decision commands, which are then sent to the server as risk decision actions.

[0152] Optionally, the virtual reality display format is used to present an interactive interface in a three-dimensional immersive environment, supporting players to make risk decisions through natural interaction. Optionally, the above-mentioned virtual reality display format can be implemented using a head-mounted display device that supports open virtual reality interface protocols, or it can rely on a standalone virtual reality all-in-one machine with spatial positioning capabilities.

[0153] Optionally, the risk negotiation scenario is used to present risk decision options in a 3D immersive environment, allowing players to handle risks without interrupting the main game.

[0154] Optionally, the aforementioned risk negotiation scenario can be an independent virtual negotiation room within the game space, or a local holographic projection area generated in the current battlefield environment. This disclosure is not intended to limit its specific visual style.

[0155] In step S2030, in response to the first player's action on at least one risk decision option, a risk decision action is determined. In this way, by transforming the player's actions on risk decision options into explicit risk decision actions, risk is shifted from passively being borne to actively engaging in the game, enhancing the strategic depth and operational controllability of the competition.

[0156] In one example, after the first player enters the decision-making state, the terminal's wheel interface displays two risk decision options: "Accept Risk" and "Avoid Risk." The first player selects the "Accept Risk" option via touch, and the system responds by determining that the corresponding risk decision action is to maintain the current high-risk, high-reward state. In another scenario, the player selects the "Delay Decision" option, and the system similarly responds by determining that the corresponding risk decision action is to sacrifice resource refresh in the next round in exchange for a delayed settlement of the current risk. Optionally, the risk decision action serves to convey the player's interactive intent regarding the risk decision option and translates it into a command form that can be recognized and settled by the server.

[0157] Optionally, the aforementioned risk decision-making actions can be any of the following actions triggered by the player in the Demon Roulette: "Accept Risk," "Avoid Risk," "Delay Decision," or "Exchange Conditions." The specific type is determined by the risk decision option selected by the player in the interactive interface. Among them, the "Accept Risk" action corresponds to the player's intention to maintain the current high-risk-reward state; the "Avoid Risk" action corresponds to the player's intention to pay health, gold, energy, or skill restriction time to reduce the risk value; and the "Delay Decision" action allows the player to delay the settlement of the current risk by locking a subsequent skill or sacrificing the next round's resource refresh.

[0158] Optionally, risk decision-making actions can also be generated via voice input, which is particularly suitable for contactless, rapid decision-making scenarios in virtual reality negotiation or augmented reality display formats. Specifically, when the terminal displays an interactive interface, the system can collect the player's voice input data through a microphone and perform real-time command recognition based on a preset set of voice commands. For example, it can map the spoken phrase "accept the risk" into a corresponding risk decision-making action.

[0159] In an optional implementation, determining the risk decision action includes: collecting voice input data while the terminal displays an interactive interface; performing command recognition on the voice input data to obtain a voice decision command; and, in response to the voice decision command matching with a preset set of voice commands, using the voice decision command as the risk decision action. In this way, risk decisions are completed through voice input without interrupting the player's current combat perspective and touch controls, effectively improving decision-making efficiency in high-pressure matches and significantly enhancing the immersive interactive experience of the risk negotiation process.

[0160] In practical applications, when the first player is within the countdown of the Devil's Roulette decision and is using the controller to move the character's view, they can directly issue the voice command "Pay the price" into the terminal microphone. After the terminal collects this voice input data, the system recognizes the command, converts the sound wave characteristics into the text "Pay the price," and compares it with candidate entries in a preset set of voice commands. If a match is found, the voice decision command is established as a risk decision action, and the server executes the corresponding risk avoidance settlement accordingly. If the player is in a virtual reality immersive battle scene, this method can avoid the loss of vision caused by the player looking down to find physical buttons, thus ensuring the continuity of the main combat line of sight.

[0161] Optionally, voice input data is captured by a microphone to pick up the player's voice and is used to generate input signals for risk decisions while the interactive interface remains on display.

[0162] Optionally, the collection of voice input data is not limited to a specific hardware form or game scenario. In one implementation, when a player needs to make a decision regarding the Devil Roulette, they can input voice through the terminal's built-in microphone, a headset microphone, or a spatial microphone array integrated into a virtual reality headset.

[0163] Optionally, a preset set of voice commands is used to compare with the recognized voice, including at least standard voice entries for accepting risk, avoiding risk, and delaying decision-making.

[0164] Optionally, a preset set of voice commands serves as a mapping benchmark between voice recognition and risk decision-making actions. Its content and matching logic can be dynamically adjusted according to different game categories and tournament rules. In one implementation, the set includes at least standardized voice entries representing "accepting risk," "paying the price," "mirroring," and "delaying settlement," with each voice entry corresponding to a specific risk decision-making action code.

[0165] In step S2040, the risk decision action is sent to the server so that the server can perform settlement based on the risk decision action and risk status information to obtain the risk settlement result. In this way, by synchronously uploading the player's risk decision action and real-time risk status to the server for centralized settlement, not only can the consistency and tamper-proof capability of the risk processing results be guaranteed, but the risk settlement result can also be generated based on the server's global perspective and the overall status of both parties, thereby effectively improving the fairness and reliability of the risk closed loop. For example, in a real-time match, the first player selects the risk decision action of "paying 30 health points to avoid the current high-risk state" in the Devil Roulette interface. The terminal then uploads this action, along with the current risk index of 85 points and the risk source of spectator interference and resource scarcity, to the server. Upon receiving this information, the server deducts 30 health points from the player according to the preset avoidance cost formula, reducing the player's risk index from 85 to 45 points. At the same time, it activates the risk reduction state and generates a risk settlement result containing "30 health points deducted, risk index reduced by 40 points, and a transfer prompt visible to the opponent." This result is then pushed to the terminals of both the first player and the opposing player, and both interfaces update the risk display elements accordingly.

[0166] Optionally, the risk settlement results are used to characterize the risk changes, profit changes, and counterparty impact generated by the settlement, so that the terminal can update the risk display elements.

[0167] Optionally, the data structure of the risk settlement result can be flexibly organized according to the actual needs of the game. It should at least include four categories of information: risk index update value, cost execution details, opponent impact summary, and status transition identifier. Among them, the risk index update value is used to indicate the player's immediate risk level after settlement; the cost execution details are used to record the avoidance costs paid, such as the amount of health deduction, gold consumption, or skill ban duration; the opponent impact summary is used to encapsulate the linkage adjustment instructions for the opponent's risk bar in the mirror game interface; and the status transition identifier is used to indicate whether the current risk event has completed the closed loop and allows the main battle process to resume.

[0168] Optionally, settlement is used to determine the change in risk, the change in return, and the counterparty's impact parameters based on risk decision-making actions and risk status information.

[0169] Optionally, the above settlement process can be executed by the server based on the current event trigger state and the player's decision state, and is not limited to simple numerical addition and subtraction logic. For example, when the risk decision action is "accept risk", the server can maintain the player's current high-yield gain flag based on the survival, resource, and confrontation dimensions data in the risk status information, while calculating the probability of a disadvantageous settlement within a future preset time window based on the risk index, and adding this probability increase as an implicit cost to the settlement output; when the risk decision action is "avoid risk", the server will extract the player's current health, gold, or skill cooldown data from the risk status information according to the preset avoidance cost mapping table, perform deductions according to the multi-dimensional cost combination rules, and simultaneously lower the risk index.

[0170] In step S2050, the risk settlement result from the server is received; and so on. In this way, by receiving the risk settlement result returned by the server, the client can promptly obtain the quantitative settlement information of the risk decision action, realizing a complete closed loop of risk decision feedback and effectively improving the real-time performance and reliability of game status synchronization. In practical applications, when the first player triggers a risk decision action on their terminal and sends it to the server, the server settles the action based on the current risk index in the quantized risk pool, generating a risk settlement result. In this receiving step, the first player's terminal receives the risk settlement result from the server through a low-latency message channel. In addition to including the risk change and profit change, the result may also include a unique event identifier and a summary of the settlement process. The specific event identifier records the trigger source, participating players, a summary of spectator influence, and the settlement status. In another implementation, if network fluctuations cause the proactive push to time out, the terminal can also initiate a polling request to the server within a specified time window to obtain the risk settlement result; if the reception still fails, the terminal marks the risk settlement request as pending resend and continues the main combat process, thereby preventing players from being stuck in operation due to waiting for the settlement response.

[0171] Optionally, this step is used to receive the risk settlement results returned by the server through a data channel to complete the closed-loop feedback of risk decision-making. Optionally, the above action of receiving the risk settlement results from the server can be implemented through various different data channels and synchronization mechanisms, and is not limited to a single push mode.

[0172] In step S2060, the risk display elements are updated based on the risk settlement results. This allows the client to instantly refresh the risk display elements according to the risk settlement results, enabling players to intuitively perceive the consequences of their decisions, forming a complete closed loop from decision-making to visual feedback, enhancing interactive immersion and system consistency. For example, in one implementation, the first player in a match selects "pay-cost avoidance" in an embedded risk negotiation interaction to reduce their own risk index. After calculating this action, the server generates a risk settlement result including the risk change, resource deduction, and the opponent's mirror feedback marker, and pushes it to the first player's terminal. The terminal parses the risk settlement result, lowers the value of its own risk bar in the interactive interface from a high-risk threshold of 75% to a medium-risk threshold of 45%, adjusts the risk bar color from red to yellow, and removes the external input risk marker next to the opponent's risk bar. Thus, players can intuitively observe the immediate state changes caused by their own decisions in a very short time after the round ends, without the delay in state perception caused by rendering latency.

[0173] Optionally, after receiving the risk settlement results, the client can perform a targeted refresh of the risk display elements to present the real-time situation after the risk decision-making loop is closed.

[0174] Optionally, after receiving the risk settlement result from the server, the client performs a targeted refresh of the risk display elements based on the risk change value, profit change value, and externally input risk labels contained in the result. These risk display elements are not limited to the client's own risk bar and the opponent's risk bar; they may also include components such as risk change rate arrows, risk source labels, and historical risk peak markers.

[0175] According to one embodiment of the present disclosure, the game interaction device may include: The acquisition module is used to acquire real-time status data from the clients of at least two players in a match. The calculation module is used to calculate the risk index of each player in the game based on real-time status data. The risk index is used to characterize the risk level of the corresponding player in the game. The first response module is used to send an interface display instruction to the target player's client when the risk index of the target player meets the preset trigger conditions, so that the client displays an interactive interface containing at least one risk decision option. The first receiving module is used to receive risk decision actions from the client, which are input by the target player in the game for at least one risk decision option included in the interactive interface; The settlement module is used to settle the risk status of the target player based on risk decision actions and the target player's risk index, thus obtaining the risk settlement result; and The synchronization module is used to synchronize risk settlement results to the clients of at least two players in the game, so as to update the risk display information on the clients.

[0176] In this way, the server centrally evaluates the real-time status data and synchronizes the settlement results to each client, reducing the computational overhead caused by decentralized processing and the network load caused by repeated transmission, reducing the rendering resource consumption of the terminal, and helping to improve the accuracy of game status synchronization.

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

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

[0179] According to one embodiment of the present disclosure, the game interaction device may include: The second receiving module is used to receive risk status information from the server, the risk status information including the risk index of the first player in the game. A display module is used to display an interactive interface on the device, the interactive interface including risk display elements drawn based on the risk index and at least one risk decision option; The second response module is used to determine a risk decision action in response to the first player's operation on the at least one risk decision option. The sending module is used to send the risk decision action to the server so that the server can perform settlement based on the risk decision action and the risk status information to obtain the risk settlement result. The third receiving module is used to receive the risk settlement result from the server; and An update module is used to update the risk display elements based on the risk settlement results.

[0180] In this way, displaying risk elements and decision options on the terminal based on a real-time risk index allows players to proactively make risk decisions, helping to reduce instruction redundancy caused by passive triggering and improving the processing efficiency of game interactions. At the same time, by providing a front-end interaction entry point for the client, it helps to reduce invalid signaling round trips between the server and the terminal, reducing the server's concurrent data processing pressure and the parsing load on the terminal side.

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

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

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

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

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

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

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

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

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

[0190] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A game interaction method, applied on a server side, the method comprising: Obtain real-time status data from the clients of at least two players in the match; Based on the real-time status data, a risk index is calculated for each player in the game. The risk index is used to characterize the risk level of the corresponding player in the game. In response to the target player's risk index meeting a preset trigger condition, an interface display instruction is sent to the target player's client to display an interactive interface, which includes at least one risk decision option. Receive risk decision actions from the client, the risk decision actions being input by the target player in response to at least one risk decision option included in the interactive interface; Based on the risk decision-making action and the risk index of the target player, the risk status of the target player is calculated to obtain a risk settlement result; as well as The risk settlement results are synchronized to the clients of the at least two players in the game to update the risk display information on the clients.

2. The method according to claim 1, wherein, The real-time status data includes data from one or more of the following dimensions: Survival dimension data includes at least one of the following: current health value, shield value, and remaining abnormal status or resurrection chance; Time-related data includes at least one of the following: match duration, phase transition points, or overtime status; Resource dimension data includes at least one of the following: remaining ammunition, remaining mana, skill cooldown status, or remaining consumable items; The combat dimension data includes at least one of the following: number of kill streaks, number of times the target was focused, duration of output exposure, or peak damage taken within a preset time window; Spatial dimension data, including at least one of the following: distance to the safe zone boundary, distance to key enemy targets, or encirclement sector determination results; and Behavioral dimension data includes at least one of the following: frequency of proactive charging, continuous firing, strong team fight initiation, or chasing down enemies with low health.

3. The method according to claim 2, wherein, The calculation of the risk index for each player in a match includes: The data of each dimension in the real-time status data are normalized to obtain normalized feature values; Based on a preset weight matrix, the normalized eigenvalues ​​are weighted to obtain weighted eigenvalues; and The risk index is generated based on the weighted feature values.

4. The method according to claim 1, wherein, The preset triggering conditions include at least one of the following: The risk index of the target player in the game is higher than a first risk threshold during a preset first duration. The risk index of the target player in the game instantly exceeds the second risk threshold, and the second risk threshold is higher than the first risk threshold. as well as The risk index difference between at least two players in a match exceeds a preset difference threshold.

5. The method according to claim 1, wherein, The method further includes: Receive audience interaction data; Semantic parsing is performed on the text data in the interactive behavior data to obtain audience emotion parameters; Based on the aforementioned audience emotion parameters, determine the audience intervention parameters; and If the audience intervention parameters meet the preset verification conditions, the result weight of the risk decision option is adjusted or the candidate event queue of the risk decision option is triggered based on the audience intervention parameters.

6. A game interaction method, applied to the terminal of a first player in a game, the method comprising: Receive risk status information from the server, the risk status information including the risk index of the first player in the game; An interactive interface is displayed on the terminal, the interactive interface including risk display elements drawn based on the risk index and at least one risk decision option; In response to the first player's action regarding the at least one risk decision option, a risk decision action is determined; The risk decision action is sent to the server so that the server can perform settlement based on the risk decision action and the risk status information to obtain the risk settlement result. Receive risk settlement results from the server; as well as Based on the risk settlement result, update the risk display element.

7. The method according to claim 6, wherein, The risk status information also includes the risk index of the opposing player; The risk display elements include a risk bar for the user and a risk bar for the opponent, which are synchronously mapped to the same visual coordinate system.

8. The method according to claim 6, wherein, The method further includes: Receive a multimodal feedback signal from the server, the multimodal feedback signal being generated based on the risk index; The multimodal feedback signal is output at the terminal.

9. The method according to claim 8, wherein, The multimodal feedback signal includes one or more of the following: Visual feedback includes at least one of the following: icon flashing, risk bar color change, screen edge tinting, or interactive interface overlay display; Haptic feedback, including vibration feedback; Audio feedback, including sound enhancement; and Control feedback, including crosshair disturbance.

10. The method according to claim 6, wherein, The method further includes: Receive risk transfer authorization information from the server; The terminal displays a risk transfer operation interface, which includes at least one risk transfer operation option, including one or more of the following: risk transfer option, skill theft option, risk mirroring option, and cost rewriting option.

11. The method according to claim 6, wherein, The method further includes: Receive audience intervention parameters from the server, the audience intervention parameters being generated based on audience interaction behavior data; A viewer intervention indicator is displayed in the interactive interface of the terminal, which is used to indicate the weight change of the at least one risk decision option.

12. The method according to claim 6, wherein, The risk-determining decision-making actions include: While the terminal displays the interactive interface, voice input data is collected; The voice input data is subjected to instruction recognition to obtain voice decision instructions; and In response to the voice decision instruction matching a preset set of voice instructions, the voice decision instruction is used as the risk decision action.

13. The method according to claim 6, wherein, The interactive interface can be displayed in augmented reality formats. In the augmented reality display mode, the interactive interface includes: The terminal's camera captures images of the real environment. Identify planar regions in the real environment; and The risk display elements are projected onto the planar area.

14. The method of claim 6, wherein, The interactive interface can be displayed in a virtual reality format. In the virtual reality display mode, the interactive interface includes: When the risk index of the first player in the game reaches a preset threshold, a risk negotiation scenario is displayed on the terminal. as well as In the risk negotiation scenario, the system receives operation input from the first player in the game, including gaze operation, gesture operation, controller pointing operation, or voice operation. Based on the operation input, the corresponding decision instruction is used as the risk decision action.

Images