An information processing method, an electronic device, and a computer-readable storage medium

Abstract

An embodiment of the present application provides an information processing method, comprising: obtaining current state data of a controlled virtual object corresponding to a target account and interaction state data around the controlled virtual object; determining a recommended action set according to the current state data and the interaction state data; and dynamically displaying at least one recommended action in the recommended action set in a graphical user interface.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an information processing method, electronic device, and computer-readable storage medium. Background Technology

[0002] In the virtual scenarios of multiplayer online applications, social interactions between virtual objects typically rely on preset actions. Related technologies often provide action-calling controls in the graphical user interface. When a user triggers this control, the terminal displays a list or wheel interface containing numerous actions. The user must browse through this list and manually select the target action to express emotions or respond to other virtual objects.

[0003] However, when users expect immediate responses, the above method requires manual searching through a large number of actions, resulting in a lengthy operation path. Each time the action list is browsed and switched, the terminal's interface rendering and interaction command processing are triggered. When users repeatedly search, the terminal needs to repeatedly process redundant interface update commands, increasing the terminal's processing load and display resource consumption, which can easily lead to response delays and reduce human-computer interaction efficiency. Summary of the Invention

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

[0005] According to one aspect of this application, an information processing method is provided, the method comprising: acquiring current state data of a controlled virtual object corresponding to a target account and interaction state data around the controlled virtual object; determining a set of recommended actions based on the current state data and the interaction state data; and dynamically displaying at least one recommended action from the set of recommended actions in a graphical user interface.

[0006] According to one aspect of this application, an electronic device is provided, comprising: a processor, a memory, and computer program instructions stored in the memory and executable on the processor; the processor, when executing the computer program instructions, implements any of the above-described information processing methods.

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

[0008] One embodiment of this application provides an information processing method, including: acquiring current state data of a controlled virtual object corresponding to a target account and interaction state data around the controlled virtual object; determining a set of recommended actions based on the current state data and interaction state data; and dynamically displaying at least one recommended action from the set of recommended actions in a graphical user interface. By automatically determining the set of recommended actions based on the current state data and interaction state data of the controlled virtual object and dynamically displaying the recommended actions in the graphical user interface, the interaction steps of manually searching for actions by the user are reduced, and the instruction redundancy of the terminal when processing and rendering a large number of action lists is reduced. Since the user does not need to repeatedly browse and switch action lists, it helps to reduce the number of times the terminal repeatedly processes redundant interface update instructions, thereby reducing the processing load and display resource occupation of the terminal, and improving human-computer interaction efficiency and system resource utilization. Attached Figure Description

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

[0010] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this application; Figure 2 This application shows a flowchart of a method in one exemplary embodiment; Figure 3a A schematic diagram of a graphical user interface in one exemplary embodiment of this application is shown; Figure 3b A schematic diagram of a graphical user interface in one exemplary embodiment of this application is shown; Figure 4 This illustration shows a schematic diagram of the structure of an electronic device according to one exemplary embodiment of the present application. Detailed Implementation

[0011] Exemplary embodiments of this application will be described more fully below with reference to the accompanying drawings.

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

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application 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 so that the embodiments of this application described herein can be implemented in orders other than those illustrated or 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.

[0014] The accompanying drawings are schematic illustrations of this application and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this application can be combined in any suitable manner in one or more implementations. In the following description, numerous specific details are provided to give a thorough description of the embodiments of this application. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this application, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0015] Figure 1 A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a graphical user interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing the game service in this exemplary embodiment; it may be a single server or a cluster of multiple servers. For example, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this application can be executed by any one or more of the terminal device 110 and the server 120.

[0016] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client 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 cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0017] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0018] According to one embodiment of the information processing method of this application, such as Figure 2 As shown, the method may include: Step S210: Obtain the current state data of the controlled virtual object corresponding to the target account and the interaction state data around the controlled virtual object; Step S230: Determine the recommended action set based on the current state data and interaction state data; Step S250: Dynamically display at least one recommended action from the recommended action set in the graphical user interface.

[0019] According to one embodiment of this application, a set of recommended actions is automatically determined based on the current state data and interaction state data of a controlled virtual object, and the recommended actions are dynamically displayed in the graphical user interface. This reduces the user's manual steps in finding actions and lowers the instruction redundancy when the terminal processes and renders a large list of actions. Since the user does not need to repeatedly browse and switch action lists, it helps reduce the number of times the terminal repeatedly processes redundant interface update instructions, thereby reducing the terminal's processing load and display resource consumption, and improving human-computer interaction efficiency and system resource utilization.

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

[0021] In step S210, the current state data of the controlled virtual object corresponding to the target account and the interaction state data around the controlled virtual object are obtained.

[0022] This provides a multimodal data foundation for subsequent identification of social contexts, enabling accurate capture of players' current interaction intentions, effectively avoiding recommendation bias caused by limited information, and improving the accuracy of action recommendations.

[0023] In one implementation, when a controlled virtual object walks in the game scene and approaches another virtual object, the system not only acquires the controlled virtual object's own current state data such as movement speed and orientation, but also simultaneously acquires the interaction state data of surrounding entities (such as a waving gesture being played by another virtual object, nearby musical instruments, and other environmental triggers). Optionally, the current state data may include information from multiple dimensions such as the controlled virtual object's position coordinates, action sequence, movement speed, and orientation angle.

[0024] Optionally, considering that players' expressive intentions in different situations are often directly influenced by their own behavioral state, the current state data mentioned above, in addition to basic movement and location information, may also include the identifier of the interactive action currently being performed by the controlled virtual object or emotional state parameters. For example, when the controlled virtual object is playing a musical instrument, its current state data will record the corresponding sequence of playing actions and their duration. It should be noted that the specific composition of the current state data described above is only one example and is not intended to limit it. In actual implementation, it can be dynamically expanded or adjusted according to the specific application scenario and recognition accuracy requirements to ensure the comprehensiveness and effectiveness of data collection.

[0025] Optionally, the interaction state data may include information such as the action data of other nearby virtual objects, the activation status of environmental triggers, and the occupancy status of specific interaction areas.

[0026] Optionally, to avoid recommendation lag caused by focusing only on one's own status and ignoring changes in the surrounding social environment, the aforementioned interaction status data can include not only the types and frequencies of interaction requests initiated by other nearby players, but also the current occupancy status of environmental triggers (such as interactive scene objects like campfires and benches). For example, when there is another virtual object playing a "waving" action around the controlled virtual object, this "waving" action and its pointing relationship will be collected in real time as interaction status data. It should be understood that the specific acquisition range of the interaction status data can be dynamically configured according to the perception radius of the controlled virtual object, and this application is not limited to this, thereby providing rich and real-time external environmental information for subsequent scene recognition.

[0027] In step S230, a set of recommended actions is determined based on the current state data and interaction state data. By comprehensively considering the current state data and interaction state data to determine the set of recommended actions, the recommended content can accurately match the real-time social context, effectively reducing the time cost for players to search for actions, minimizing social disconnections, and improving the smoothness and naturalness of interaction. In one implementation, when a controlled virtual object encounters and approaches another virtual object in the game scene, the system acquires the positional state data of the controlled virtual object and the action sequences of nearby virtual objects, thereby identifying the current situation as a first encounter. Furthermore, waving and bowing are identified as actions in the recommended action set, allowing players to directly select and execute them when the interaction interface is accessed.

[0028] Optionally, the recommended action set may include at least one candidate action, which is dynamically determined based on the evaluation results of the current scenario and is used for immediate triggering and execution by the controlled virtual object. Optionally, the recommended action set may be a set of one or more actions selected based on the results of multimodal data fusion recognition. Considering the pain point that players may want to express themselves in social interactions but do not have time to find suitable actions, as a possible implementation, the determination of the recommended action set may include: identifying the intent matching degree of the current social context and selecting candidate actions from the full action library accordingly. For example, when the controlled virtual object and the target virtual object complete a piano performance, the system recognizes the end of the performance and includes clapping and bowing in the recommended action set; another example is when the target virtual object is detected to have changed to a cute outfit, actions expressing liking are included in the set; yet another example is when the controlled virtual object does not react to the target virtual object's actions for a long time, confused facial expressions are included in the set. It should be noted that the number of actions in the recommended action set can be flexibly adjusted according to the interface display space and the complexity of the scenario, and this application does not intend to limit the specific composition of the set. This collection can be dynamically updated at different stages of social interaction to ensure that recommended content remains in sync with the real-time context.

[0029] In an optional implementation, a set of recommended actions is determined based on current state data and interaction state data, including: identifying the current scenario based on the current state data and interaction state data; and evaluating candidate actions based on the current scenario to determine the set of recommended actions. This two-stage processing mechanism, which first identifies the current scenario and then evaluates candidate actions, can accurately match the social context of the controlled virtual object, thereby effectively improving the contextual adaptability of recommended actions and reducing the search cost and interaction latency for players during action selection.

[0030] In one implementation, when a controlled virtual object encounters another virtual object in a virtual scene, the system acquires the controlled virtual object's current state data, such as its position coordinates and orientation angle, as well as interaction state data, such as the action sequences and environmental trigger states of other nearby virtual objects. Based on this data, the system identifies the current scene as a social encounter scene. Subsequently, the system extracts candidate actions from the entire available action library, such as bowing, waving, and clapping, and evaluates these candidate actions based on the current scene. For example, in a social encounter scene, bowing and waving receive higher evaluation scores and are therefore included in the recommended action set. Similarly, when a controlled virtual object and a target virtual object have just completed a musical performance interaction, the system identifies the current scene as a performance ending with thanks; in this case, candidate actions such as clapping and bowing receive higher evaluation scores and are preferentially included in the recommended action set.

[0031] Optionally, the current scenario can include social encounter scenarios, interaction-ending gratitude scenarios, and area-staying scenarios, which are determined based on a comprehensive analysis of state data and interaction state data. Optionally, the identification of the current scenario can be achieved through multimodal data fusion, specifically including various context types such as social encounter scenarios, interaction-ending gratitude scenarios, area-staying scenarios, and costume appreciation scenarios. Considering the significant differences in the social feedback required by players in different scenarios, as a possible implementation method, the system can adopt a scenario determination mechanism based on conditional rules. Based on the position coordinates, action sequence, and behavioral states of other nearby virtual objects of the controlled virtual object, the system matches the category of the current scenario layer by layer through a preset scenario determination rule tree. Specifically, this scenario determination rule tree uses distance change trends and the action states of both parties as primary determination features, and environmental trigger states and time nodes as auxiliary determination features, performing conditional matching according to feature priority. For example, when the distance between the controlled virtual object and the target virtual object gradually decreases and both are in a static standing state, the matching is a social encounter scenario; when both parties continuously perform music performance actions within a preset time period and the performance actions cease, the matching is an interaction end and thanks scenario; furthermore, when the controlled virtual object stays in a specific interactive area for a duration exceeding a time threshold and there is an active environmental trigger nearby, the matching is an area dwelling scenario. It should be noted that the above scenario type classification is only one example, and this application does not intend to limit the composition of the current scenario. In actual implementation, scenario types can be further subdivided based on dimensions such as the activation state of environmental triggers, day / night cycles, and weather conditions to ensure the accuracy of matching recommended actions with the context.

[0032] Optionally, candidate actions can include social actions, performance actions, and emotional expression actions, which are extracted from the available action library and evaluated and filtered based on the current scenario. Optionally, candidate actions can be a set of actions to be evaluated extracted by the system from the entire available action library, specifically including various types such as social actions (e.g., bowing, waving, hugging), performance actions (e.g., playing the piano, dancing, drumming), and emotional expression actions (e.g., clapping, confused expressions, expressions of affection). To avoid excessive computational load due to an excessive number of candidate actions, the above method can perform preliminary filtering based on the type of the current scenario when extracting candidate actions. For example, in a social encounter scenario, social actions and emotional expression actions can be prioritized as candidate actions, while performance actions can be temporarily excluded. Based on this, the evaluation process of candidate actions can specifically include: determining a basic matching value based on the semantic relevance of the candidate action to the current scenario, adjusting the basic matching value based on attribute parameters such as the execution duration and triggering conditions of the candidate action, and finally sorting and filtering the candidate actions based on the adjusted matching values. It should be understood that, in addition to automatically extracting and determining candidate actions through the system, a subset of priority actions set by the player can also be received as a supplementary source of candidate actions, and this application does not limit this.

[0033] In an optional implementation, candidate actions are evaluated based on the current scenario to determine a set of recommended actions. This includes: determining matching parameters between candidate actions and the current scenario based on current state data and interaction state data; and filtering the candidate actions to obtain a set of recommended actions based on the matching parameters. By quantifying the matching parameters between candidate actions and the current scenario, objective data is provided for subsequent filtering, effectively avoiding context mismatch caused by subjective random recommendations, thereby improving the fit between recommended actions and the social context.

[0034] In one implementation, when a controlled virtual object has just completed a musical instrument performance interaction, the system acquires current state data including a "performance ended" status marker and interaction state data including that another nearby virtual object is in a "facing this object and standing still" state. Based on this data, the system identifies the current scene as a "performance acknowledgment scene" and then evaluates each action in the candidate action library. For example, the matching parameter for the "clapping" action is 0.92, the matching parameter for the "bowing" action is 0.88, while the matching parameter for the "waving goodbye" action is only 0.35. Accordingly, the system includes the "clapping" and "bowing" actions with higher matching parameters into the recommended action set for the player to choose and trigger immediately.

[0035] Optionally, the matching parameter is used to characterize the degree of fit between the candidate action and the current scene. It is calculated by multimodal fusion based on the current state data and the interaction state data.

[0036] Optionally, the matching parameter characterizes the degree of fit between the candidate action and the current scene, and is calculated through multimodal fusion based on the current state data and interaction state data. Alternatively, the matching parameter can be a numerical score obtained by weighted fusion calculation after extracting multi-dimensional features from the current state data and interaction state data. Specifically, the system first extracts the position features, action sequence features, and time node features of the controlled virtual object from the current state data, and simultaneously extracts the action features of nearby virtual objects, environmental trigger state features, and relative position features between objects from the interaction state data. Then, the above multi-dimensional features are input into a preset intent matching model, which calculates the cosine similarity between the feature vector of the candidate action and the feature vector of the current scene, and outputs a matching score between 0 and 1 as the matching parameter. The closer the matching parameter is to 1, the higher the degree of fit between the candidate action and the current social context. For example, in a performance acknowledgment scenario, the matching parameter for the "clapping" action is 0.92, the matching parameter for the "bowing" action is 0.88, while the matching parameter for the "waving goodbye" action is only 0.35. Similarly, in a social encounter scenario, when the controlled virtual object and the target virtual object meet for the first time and both are standing still, the matching parameter for the "waving" action is 0.85, the matching parameter for the "bowing" action is 0.79, while the matching parameter for the "drumming" action is only 0.20. It should be noted that the calculation method for matching parameters is not limited to the cosine similarity method mentioned above. A rule-based scoring mechanism can also be used, which involves pre-setting several matching rules for different scenario types, evaluating the suitability of candidate actions one by one, accumulating scores, and finally normalizing the results to obtain the matching parameters. Calculating matching parameters through multimodal data fusion can objectively quantify the contextual suitability of candidate actions and provide basic data support for subsequent comprehensive ranking combining popularity weights and personalization weights.

[0037] Optionally, in addition to using the numerical scoring method mentioned above, matching parameters can also be represented using hierarchical labels. For example, matching parameters can be divided into four levels: "high match," "medium match," "low match," and "no match," with each level corresponding to a preset numerical range. During the calculation process, the system can first perform coarse-grained matching based on the mapping table between scene types and candidate action types to determine the initial level. Then, it can perform fine-grained adjustments by combining dynamic features in the interaction state data (such as the duration of the other player's action and the time interval between actions) to finally determine the level of the matching parameters. Considering that players have different needs for recommendation accuracy in different social scenarios, the system can also dynamically adjust the calculation strategy of matching parameters according to the urgency of the scenario. For example, in urgent scenarios where an interaction request is detected from another player, a simplified fast matching algorithm is used to reduce computational latency and ensure that recommended actions can be generated in a very short time. In non-urgent exploration scenarios, a complete multimodal fusion algorithm is used to improve recommendation quality. If a candidate action cannot be determined to match in the current scenario, the system can set its matching parameters to the intermediate value by default and use subsequent popularity weights and personalization weights to assist in the judgment. This application embodiment does not limit this.

[0038] In an optional implementation, a set of recommended actions is obtained by filtering candidate actions based on matching parameters. This includes: acquiring group action trend data, which includes the server-wide usage frequency of each candidate action within a preset time period; determining the popularity weight value of each candidate action based on the server-wide usage frequency; and obtaining the set of recommended actions by filtering candidate actions based on matching parameters and popularity weight values. By introducing group action trend data and combining it with popularity weight values ​​for filtering, the recommended actions not only fit the current scenario but also reflect the server-wide social hot topics, thereby increasing the group resonance of the recommended content and players' willingness to accept it.

[0039] For example, in a social scene involving music performance within a game, the system first identifies the current scene as the "performance ended" stage and calculates that the two candidate actions, "clapping" and "bowing," have high matching parameters with this scene. Simultaneously, the system obtains the usage frequency of each candidate action across all players in the past 72 hours, finding that the "clapping" action has been used 58,000 times across the entire server, while the "blowing kiss" action has only been used 3,200 times. Based on this, the system determines the popularity weight value for "clapping" to be 0.9, and the popularity weight value for "blowing kiss" to be 0.1. Finally, the system weights and merges the matching parameters and popularity weight values. The "clapping" action, due to its high scene matching degree and popularity weight value, is prioritized for inclusion in the recommended action set and displayed to players. Similarly, during holiday events, the usage frequency of the "holiday-exclusive dance" action may surge across the entire server, increasing its popularity weight value. Even if its scene matching parameters are slightly lower than other actions, it may still be included in the recommended action set due to its popularity advantage, allowing players to experience the holiday social atmosphere.

[0040] Optionally, group action trend data may include the server-wide usage frequency of each candidate action within a preset time period, reflecting the overall preference trend of players' social behavior across the entire server. Optionally, group action trend data refers to a statistical dataset collected and aggregated from the global server perspective, reflecting the distribution of a large number of players' social action usage. In addition to the server-wide usage frequency of each candidate action, this dataset may also include statistical information from other dimensions, such as the usage distribution ratio of each candidate action in different map areas, different time periods, or different social relationship chain levels. This extended information can further help the system characterize the spatial and temporal features of action popularity trends. It should be noted that the collection scope of group action trend data can be flexibly adjusted according to actual operational needs. It can cover all data from all servers or sample only data from a representative subset of servers to reduce collection overhead. Considering the time-sensitive nature of social action popularity trends, group action trend data can be updated on a rolling basis at a fixed cycle, such as every 6 hours or daily, to ensure that the recommendation results reflect the latest social hotspots in a timely manner. In addition, when dealing with large amounts of data, a sliding window mechanism can be used to smooth historical data and avoid drastic fluctuations in popularity assessments due to short-term unforeseen events.

[0041] Optionally, the preset time period is used to define the statistical time range of group action trend data, which can be dynamically configured according to operational needs or scenario cycles. Optionally, the preset time period refers to the time window parameter used by the system when statistically analyzing group action trend data, and its specific value can be flexibly set according to different business scenarios and operational strategies. As one possible implementation, the preset time period can be set to a shorter time window, such as the last 24 hours or the last 6 hours. This configuration can keenly capture social hotspots emerging in the short term and is suitable for scenarios requiring rapid response, such as holiday events or limited-time gameplay. As another implementation, the preset time period can also be set to a longer time window, such as the last 7 days or the last 30 days. This configuration focuses more on reflecting the long-term stable preferences of players' social behavior and is suitable for eliminating the impact of occasional fluctuations in daily recommendation scenarios. It should be noted that the specific value of the preset time period is not fixed and can be adaptively adjusted according to whether the current operation cycle is in a special period. For example, during a game anniversary celebration, the system can automatically shorten the preset time period to 12 hours to more accurately track the popular trend changes of celebration-exclusive actions; while during regular operation periods, it reverts to the default configuration of 72 hours. In addition, the preset time period can be associated with the day-night cycle or season cycle in the game, so that the statistics window keeps in sync with the player's natural game rhythm.

[0042] Optionally, server-wide usage frequency is used to characterize the cumulative number of times each candidate action is triggered by players across the server within a preset time period, serving as the basic data for popularity assessment. Optionally, server-wide usage frequency refers to the total number of times a candidate action is triggered by all eligible players across the server within a preset time period. This frequency data can be statistically analyzed in various ways. One possible implementation is that the system can accumulate and count each action trigger event in real time, resetting it at the start of the preset time period to obtain an accurate cumulative value. Another implementation, considering the resource overhead of real-time counting, can also use a sampling estimation method. This involves extracting a certain proportion of samples from the server-wide data for statistical analysis, and then using the sampling proportion to estimate an approximate server-wide usage frequency. This method can effectively reduce server load when the data volume is extremely large. It should be noted that the statistics for server-wide usage frequency can further distinguish between different trigger sources. For example, the system can separately count player-initiated actions and system-guided actions, using only the number of active triggers when calculating the popularity weight value to eliminate interference from system intervention in the popularity assessment. In addition, the system can set up a deduplication mechanism to prevent the same player from repeatedly triggering the same action within a short period of time. For example, multiple triggers of the same action by the same account within 5 minutes will only be counted as one, thereby avoiding the deviation of the accuracy of the usage frequency data of the whole server caused by the action-farming behavior of individual players.

[0043] Optionally, the popularity weight value is used to quantify the popularity of each candidate action across the entire server, serving as an auxiliary decision-making basis for selecting and recommending action sets. Optionally, the popularity weight value is a quantitative indicator used to characterize the popularity of candidate actions across the entire server, calculated based on their usage frequency. This weight value can be calculated using various strategies. One possible implementation is to directly normalize the usage frequency of each candidate action across the entire server; for example, mapping the most frequent action to 1.0 and scaling the remaining actions proportionally to obtain a popularity weight value between 0 and 1. Another implementation is to use a logarithmic function to compress and transform the usage frequency across the entire server before normalization, to reduce the weight gap between popular and unpopular actions and avoid popularity factors excessively dominating the recommendation results. It should be noted that the popularity weight value works in conjunction with the matching parameters in the final selection process, and the fusion method between the two can be flexibly configured according to actual needs. For example, the system can use a weighted summation method, multiplying the matching parameters and popularity weights by preset coefficients and then adding them together to obtain a comprehensive score; alternatively, it can use a multiplicative fusion method, directly multiplying the two to ensure that only actions with high scene matching and popularity receive a high comprehensive score. Furthermore, the popularity weights can be configured with a decay factor, causing the weight of historically high-frequency actions to gradually decrease over time, thus leaving room for recommending emerging popular actions and maintaining the freshness and diversity of the recommended content.

[0044] In an optional implementation, a set of recommended actions is obtained by filtering candidate actions based on matching parameters. This includes: acquiring historical social preference data of the target account, which includes the frequency and / or usage scenarios of each candidate action used by the target account in historical interactions; determining a personalized weight value for each candidate action based on the historical social preference data; and obtaining a set of recommended actions by filtering candidate actions based on the matching parameters and personalized weight values. By incorporating the historical social preference data of the target account to calculate personalized weight values, the recommended actions are made to fit both the current context and the player's personal expression habits, effectively improving the accuracy of recommendations and the player's willingness to use them.

[0045] In one implementation, taking the social interaction of a player corresponding to a target account within the game as an example: The system obtains the historical social preference data of the target account over the past 30 days and finds that the player frequently uses the "bowing" action in greeting scenarios (42 times), and frequently uses the "clapping" action when admiring others' outfits (15 times in outfit display scenarios). Based on this, the system determines that the personalized weight value of the "bowing" action in greeting scenarios is 0.85, and the personalized weight value of the "clapping" action in outfit display scenarios is 0.78. When the matching parameters show that the current scenario is a greeting scenario and the matching degree is 0.9, the system calculates that the "bowing" action has the highest comprehensive score by combining the matching parameters and personalized weight values, and selects it for priority display in the recommended action set. Furthermore, if the player recently starts to frequently use the "waving" action instead of "bowing," the system will correspondingly increase the personalized weight value of "waving" to ensure that the recommended content reflects the player's latest expression preferences.

[0046] Optionally, historical social preference data is used to record the target account's preference for each candidate action in historical social interactions, including at least one of usage frequency and usage scenario records. Optionally, historical social preference data can be statistical information on the target account's social behavior within a preset time period (e.g., the last seven days, the last thirty days, or since account creation). In addition to the usage frequency of each candidate action, this data can also include other dimensions of information, such as the corresponding interaction object identifier, interaction duration, and interaction result feedback (e.g., whether the other party responded). This extended information can further assist the system in more accurately portraying the player's expression habits. It should be noted that the above description of the information types included in historical social preference data is only one example and is not intended to limit its composition. Considering the significant differences in social activity among different players, as a possible implementation method, for accounts with low social activity, the system can appropriately extend the data statistics time window or introduce group preference data from similar accounts to supplement it, ensuring that the calculation of personalized weight values ​​has a sufficient data foundation and avoiding distortion of recommendation results due to data sparsity.

[0047] Optionally, the usage scenario record is used to characterize the context in which the target account triggered each candidate action in historical interactions, and it is dynamically determined based on the scenario type and triggering time. Optionally, the usage scenario record can include multiple scenario types, such as social greeting scenarios (e.g., greetings when players meet), performance interaction scenarios (e.g., thanking someone after showcasing talents like playing an instrument or dancing), costume display scenarios (e.g., showing off a player's appearance to others after changing their appearance), and special event scenarios (e.g., specific interactions during seasonal events). In one implementation, the usage scenario record not only records the scenario type but also the specific timestamp of the triggered action in that scenario, the relative distance to the interaction object at the time of triggering, and whether subsequent chain interactions occurred after the triggering. To avoid deviations in the usage scenario record due to scenario recognition errors, the above method can perform cross-validation based on multiple environmental parameters (e.g., location coordinates, nearby entity status, time nodes) when recording scenario information to ensure the accuracy of scenario classification. It should be understood that the granularity of the usage scenario record can be flexibly adjusted according to the system's storage capacity and computing resources; it can record each interaction independently or aggregate statistics by scenario type.

[0048] Optionally, the personalized weight value is used to quantify the degree of matching between each candidate action and the target account's personal expression habits, and it is dynamically calculated based on historical social preference data. Optionally, the determination of the personalized weight value is not only related to the historical usage frequency of a single action, but also to multiple factors such as the usage ratio of the action in a specific scenario, recent usage trend changes, and the stability of the player's preference for that action. Based on this, the calculation process of the above-mentioned personalized weight value can specifically include: determining the basic preference value based on the total usage frequency of each candidate action in the historical social preference data, determining the scenario adaptation coefficient based on the historical usage ratio of the action in the current matching scenario, and calculating the personalized weight value based on the product of the basic preference value and the scenario adaptation coefficient. It should be noted that if the historical data of the target account is insufficient to support the weight calculation (e.g., a newly registered account or very little social interaction), a default weight value or reference to group action trend data can be used for alternative calculations; this application embodiment does not limit this. Furthermore, the personalized weight value can be periodically updated as player behavior changes to ensure that the recommendation results always reflect the player's latest expression preferences.

[0049] In an optional implementation, a set of recommended actions is obtained by filtering candidate actions based on matching parameters. This includes: acquiring group action trend data and historical social preference data of the target account; determining the popularity weight value of each candidate action based on the group action trend data, and determining the personalized weight value of each candidate action based on the historical social preference data; and obtaining the set of recommended actions by filtering candidate actions based on matching parameters, popularity weight values, and personalized weight values. By combining scene matching degree, group popularity, and personal preference for multi-dimensional weight filtering, the recommended actions not only conform to the current context and popular trends, but also fit the player's personal expression habits, thereby significantly improving the adoption rate of recommendation results and the personalized experience of social interaction.

[0050] In one implementation, when the system needs to filter recommended actions for a player, it simultaneously retrieves the player's frequently used action records from the past week and a list of the top ten most used actions by all players in the past hour. For example, if the current scenario is two players having just finished a musical duet, after recognizing this scenario, the system calculates the scenario matching parameter for the "clapping" action as 0.9. Simultaneously, because "clapping" has a high recent usage frequency across the server, its popularity weight is 0.8; and the target account's historical preference data shows that it prefers to use "bowing" to express gratitude, so the personalized weight value for "bowing" is 0.9. The system combines these three parameters and ultimately includes both "bowing" and "clapping" in the recommended action set, displaying them preferentially on the interface. It should be noted that the specific weight calculation ratio can be dynamically adjusted according to operational needs, and this application does not impose any limitations on this.

[0051] Optionally, a multi-dimensional weighted filtering mechanism integrates matching parameters, popularity weight values, and personalized weight values ​​to comprehensively calculate and filter the recommended action set. Optionally, the multi-dimensional weighted filtering mechanism can be a comprehensive scoring model based on scene matching parameters, popularity weight values, and personalized weight values. Considering that relying solely on scene matching may not simultaneously consider both public aesthetics and individual habits, this mechanism aims to achieve accurate recommendations through multi-source data fusion. Specifically, the matching parameters, popularity weight values, and personalized weight values ​​can be multiplied by their corresponding preset coefficients and then summed to obtain the comprehensive recommendation index for each candidate action. For example, for the "waving" action, if its scene matching parameters are high, its usage frequency ranks high across the server, and it is also frequently used in the player's history, then its comprehensive recommendation index will be significantly higher than other actions. It should be noted that the specific proportions of the above weights are not fixed and can be dynamically configured according to the priority of different social contexts. For example, the proportion of popularity weight values ​​can be appropriately increased during holiday events to ensure that the recommendation results are both timely and tailored to individual needs. This application does not intend to exhaustively limit the specific calculation formula.

[0052] Optionally, besides using a linear weighted summation method to calculate the comprehensive recommendation index, other multi-dimensional data fusion strategies can be employed to determine the final set of recommended actions. One possible implementation is to set threshold conditions for each weight value and use a funnel-style filtering mechanism. First, a first candidate set matching the current scenario is selected based on matching parameters. Then, actions with popularity weight values ​​below a specified threshold are removed from this set. Finally, the remaining actions are sorted according to their personalized weight values, and the top-ranked actions are selected as the recommended action set. This hierarchical filtering method effectively reduces data processing volume while ensuring the contextual relevance of the recommended actions. Furthermore, if there is an extreme conflict between the personalized weight value and the popularity weight value of a candidate action, the system can further introduce a random perturbation factor or provide an expansion entry point to avoid an overly simplistic recommendation list and improve the diversity and fault tolerance of social interactions.

[0053] In an optional implementation, the method further includes: detecting preset events, which include at least one of the following: receiving an interaction request initiated by another virtual object, detecting that a controlled virtual object has entered a designated area, or detecting that the distance between the controlled virtual object and the target virtual object is less than a distance threshold; and updating the recommended action set in response to detecting the preset event. By actively detecting preset events and updating the recommended action set in a timely manner, social feedback needs can be anticipated, ensuring that players receive appropriate actions in a timely manner when specific situations occur, effectively reducing social delays and breakpoints.

[0054] In one implementation, a preset event is triggered when the system detects an interaction request from another virtual object to the controlled virtual object, or when the controlled virtual object enters the designated area of ​​the campfire gathering point, or when the distance between the controlled virtual object and another player-controlled target virtual object is less than a distance threshold of 2 meters. At this time, the system silently updates the recommended action set in the background, prioritizing actions such as "hug," "high-five," or "sit down" that fit the current context, so that players can directly select them when they bring up the interface. Optionally, the preset event represents the specific conditions that trigger the update of the recommended action set, and it includes at least situations such as interaction requests, entering an area, or approaching a target.

[0055] Optionally, preset events can take the form of receiving an interaction request initiated by another virtual object, detecting a controlled virtual object entering a designated area, or detecting that the distance between a controlled virtual object and a target virtual object is less than a distance threshold. Considering that social interactions are often spontaneous and context-dependent, to avoid delays caused by players manually searching for actions when they need to respond, the above preset event settings aim to capture the key moments of social triggering. Specifically, interaction requests can include, but are not limited to, hug invitations, musical instrument ensemble invitations, or message viewing requests from other virtual objects; designated areas can include, but are not limited to, scenic check-in points, task interaction points, or campfire rest areas; distance thresholds can be dynamically adjusted according to the map scale, for example, set to any value between 1.5 meters and 3 meters. It should be noted that the above description of preset event types is only one example and is not intended to limit them. In actual implementation, it can also be combined with the state changes of environmental triggers (such as day-night cycle, weather changes) for comprehensive judgment.

[0056] Optionally, in addition to determining preset events directly based on physical location or explicit requests, implicit preset events inferred from behavioral sequences can also be received. To avoid misjudgments due to lost interaction requests or detection delays caused by network fluctuations, the above method can also introduce a fault-tolerance mechanism when detecting preset events. If a jitter occurs where the distance between the controlled virtual object and the target virtual object suddenly increases and then decreases, the system will not immediately trigger the preset event corresponding to the distance threshold, but will instead perform secondary confirmation by setting a duration threshold (e.g., maintaining close proximity for more than 0.5 seconds). For states that cannot be clearly classified into the above three situations but have social potential, an auxiliary recognition model can be used to evaluate the player's current action sequence. If the evaluation score exceeds a safety threshold, it is also considered that a preset event has occurred. This application embodiment does not limit this.

[0057] Optionally, the recommended action set can be updated to dynamically adjust the order and content of candidate actions after a preset event occurs, in order to adapt to real-time interaction needs.

[0058] Optionally, the process of updating the recommended action set can specifically include: extracting corresponding candidate response actions from a pre-configured mapping relationship based on the type of preset event, and recalculating the display priority of these actions according to the matching parameters of the current scene. By completing the set update instantly upon the occurrence of the event, the computational load when the graphical user interface is invoked can be reduced, and the player can be ensured to see the freshest and most context-appropriate recommended content. Based on this, the update operation can not only add new actions, but also remove actions that are no longer applicable, or adjust the order of existing actions. Before the graphical user interface is invoked, the updated recommended action set is preloaded into the fast access area of ​​memory, so that it can be directly read and displayed during interface rendering, thereby achieving a seamless, real-time response experience.

[0059] In an optional implementation, in response to the detection of a preset event, the recommended action set is updated, including: preloading candidate response actions corresponding to the preset event after the preset event is detected but before the graphical user interface is invoked; and updating the candidate response actions to a priority display position in the recommended action set so that the candidate response actions are directly displayed for immediate triggering when the graphical user interface is invoked. By preloading candidate response actions and updating them to a priority display position before the interface is invoked, players can trigger a response immediately upon opening the interactive interface, effectively shortening the social feedback path and reducing social delays and breakpoints.

[0060] In one implementation, when the system detects that other nearby virtual objects are waving at the controlled virtual object, the system background begins preloading candidate response actions corresponding to "waving," such as "wave response" and "bowing." These candidate response actions are then prioritized in the recommended action set. When the player subsequently opens the action interaction interface, the first screen directly displays the two recommended actions, "wave response" and "bowing," allowing for instant social feedback without page turning or searching.

[0061] Optionally, candidate response actions refer to recommended actions that correspond to preset events. These actions are dynamically determined based on the type of the preset event and are used by players to trigger them instantly when the interface is invoked. Optionally, candidate response actions can be action data pre-calculated and cached by the system through a background preloading mechanism after detecting a preset event and before the graphical user interface is invoked. Considering the pain point of "wanting to express something but not having time" in social interactions, the determination of the aforementioned candidate response actions can include: when detecting an interaction request initiated by another virtual object (e.g., waving or hugging), the system matches the corresponding response type action from the action library as a candidate response action based on the type of the interaction request. For example, when the other party initiates a "wave," candidate response actions can include "wave back" and "nod in greeting"; when the other party finishes "playing an instrument," candidate response actions can include "clapping" and "bowing in thanks." It should be noted that the number and types of candidate response actions are not limited to the above examples. The system can further refine the scope of candidate response actions based on the state of environmental triggers. For example, if the system detects the end of a performance near a campfire, "dancing" can be added as a candidate response action. Through the preloading mechanism, the candidate response actions have completed data preparation before the interface is invoked, avoiding the real-time calculation delay after the interface is opened.

[0062] Optionally, in addition to determining candidate response actions based on interaction requests initiated by other virtual objects, candidate response actions can also be determined based on the controlled virtual object entering a designated area or changes in distance from the target virtual object. As a possible implementation, when a controlled virtual object is detected entering a designated area such as a social plaza, the system can preload general social candidate response actions such as "greeting" or "bowing." When the distance between a controlled virtual object and a target virtual object is detected to be less than a preset distance threshold (e.g., 3 meters), the system can further preload candidate response actions related to the target virtual object's style or historical interaction records. For example, if the target virtual object is dressed in a cute style, a "expressing affection" candidate response action can be preloaded. If multiple preset events are triggered simultaneously, the system can sort and merge candidate response actions according to preset priority rules to ensure that the final presented candidate response actions cover the current context without overloading the interface space.

[0063] Optionally, the priority display position refers to the area in the graphical user interface with the highest visual focus priority, which is used to directly present candidate response actions for immediate triggering when the interface is invoked.

[0064] Optionally, the priority display position can be the default focus area of ​​the graphical user interface, the visible area on the first screen, or a momentary recommended position on the first path of the interactive interface. Considering that the area where a player's gaze first falls after calling up the interactive interface is usually in the center or top of the interface, the aforementioned priority display position can be set in the central area of ​​the action interactive interface, or it can be set at the top of the interface near the crosshair indicator or other positions with high visual focus characteristics. In one specific approach, when the graphical user interface is invoked, the priority display position is presented as an independent recommended position, and its visual style is consistent with the original interface style, such as using the same icon border style and color scheme, to avoid player resistance due to abrupt style. It should be noted that the number of priority display positions can be dynamically adjusted according to the number of candidate response actions, and this application does not intend to limit the specific number and layout of priority display positions. By placing candidate response actions in priority display positions, players can see and trigger the target action the moment the interface is opened, without the need for additional page turning or scrolling operations.

[0065] In step S250, at least one recommended action from the recommended action set is dynamically displayed in the graphical user interface.

[0066] By dynamically displaying recommended actions in the graphical user interface, players can intuitively obtain the most appropriate action in the current situation, effectively reducing search costs and thus improving the immediacy and smoothness of social feedback.

[0067] For example, when the system recognizes that the current scene represents two players finishing an instrumental duet, the recommended action set includes actions such as "clapping" and "bowing." At this time, the recommended action "clapping" is dynamically displayed as a semi-transparent icon in the visible area of ​​the first screen of the graphical user interface corresponding to the controlled virtual object. The player can click this icon to execute the action immediately without having to open a deep action list to find it. For example, Figure 3a As shown, the graphical user interface 300 displays a game scene, which includes a controlled virtual object 301 and a target virtual object 302. The target virtual object is a virtual object controlled by another user. The graphical user interface 300 displays a recommended action trigger control 310. In response to the player's touch operation on the recommended action trigger control 310, the controlled virtual object 301 immediately executes the corresponding recommended action. The recommended action trigger control 310 can be displayed above the head of the controlled virtual character 301.

[0068] In an optional implementation, dynamically displaying at least one recommended action from the recommended action set in the graphical user interface includes: in response to the controlled virtual object's viewpoint crosshair aligning with the target virtual object, displaying at least one recommended action from the recommended action set associated with the target virtual object in the graphical user interface.

[0069] The graphical user interface displays a view reticle. When the reticle falls within the detection range of the target virtual object, a recommended action icon associated with the target virtual object automatically appears above the target virtual object's head. In response to the player's touch on this recommended action icon, the controlled virtual object immediately executes the corresponding recommended action. For example, ... Figure 3a As shown, the current scene displayed in the graphical user interface 300 is the target virtual character 302 watching the performance of the target virtual character 303. When the crosshair of the controlled virtual character's view is aligned with the target virtual object 302, a crosshair indicator 320 is displayed above the head of the target virtual object 302 to indicate the currently selected virtual object. At this time, a recommended action indicator 310 (such as a "greet" icon) is displayed above the head of the controlled virtual character 301. In response to the player's touch operation on the recommended action indicator 310, the controlled virtual object 301 is controlled to perform a greeting action towards the target virtual character 302. For example, as... Figure 3b As shown, the current scene displayed in the graphical user interface 300 is the target virtual character 302 watching the performance of the target virtual character 303. When the crosshair of the controlled virtual character's view is aligned with the target virtual object 303, a crosshair indicator 320 is displayed above the head of the target virtual object 303 to indicate the currently selected virtual object. At this time, a recommended action indicator 311 (such as a "clapping" icon) is displayed above the head of the controlled virtual character 301. In response to the player's touch operation on the recommended action indicator 310, the controlled virtual object 301 is controlled to perform the "clapping" action. This eliminates the need for additional buttons to bring up the interactive interface, reducing the operational hierarchy. Based on the game context of the current scene, it achieves WYSIWYG real-time action recommendations, effectively reducing the delay in social feedback.

[0070] In one implementation, when a player controls a controlled virtual object to explore the game scene, if the player aims their view at a nearby unfamiliar player (i.e., the target virtual object), the system will automatically display a recommended action associated with that target virtual object at a designated location in the graphical user interface (such as above the target virtual object's head or near the crosshair), such as "waving" or "bowing." Furthermore, if the target virtual object has just finished playing a musical instrument, the displayed recommended action will automatically switch to "clapping," and the player can simply click on this recommended action to respond instantly, without having to search through a complex action list.

[0071] Optionally, the view reticle is used to indicate the focus position of the controlled virtual object's gaze in the graphical user interface, serving as a spatial reference for triggering recommended action displays. Optionally, the view reticle can be a fixed icon displayed in the center of the graphical user interface, or it can be a hidden projection point of the judgment ray on the screen. Considering the player's need to quickly shift attention in a 3D scene, the view reticle is not limited to the exact center of the screen; its equivalent position can be dynamically calculated based on the camera's deflection angle. It should be noted that the judgment range of the view reticle can be a precise coordinate point, or a circular or polygonal area with a certain radius to accommodate slight jitter caused by player operation. Through this spatial alignment mechanism, the system can accurately capture the player's interaction intent, avoiding frequent pop-up of recommended actions when the player has no clear social interaction target, thus improving the accuracy and immersion of the interaction.

[0072] Optionally, the target virtual object is used to represent the object that the controlled virtual object intends to interact with in the current scene, and it is dynamically determined according to the direction of the viewpoint reticle.

[0073] Optionally, the target virtual object can be another player character belonging to the same faction as the controlled virtual object, or it can be a non-player character or an interactive environmental object. In one specific implementation, when the view's crosshair falls within the collision box of a virtual object, that virtual object is marked as the target virtual object. Furthermore, to prevent the determination of a single object from being too limited, the target virtual object can also include a set of multiple virtual objects within the view's crosshair's determination range, from which the system can select the final target based on the nearest distance principle or interaction priority. By flexibly defining the scope of the target virtual object, the system can adapt to the interaction needs of different social scenarios, ensuring that the recommended actions accurately match the player's current social objects.

[0074] In an optional implementation, at least one recommended action from the recommended action set is dynamically displayed in the graphical user interface, including: dynamically displaying at least one recommended action from the recommended action set in the default focus area or the visible area of ​​the first screen of the graphical user interface. This avoids players having to flip through pages in a complex action list, allowing recommended actions to directly fall within the player's visual focus and first screen operation range, thereby significantly reducing the cost of reaching the user, achieving instant expression, and effectively reducing social disconnections.

[0075] In one implementation, when a player interacts with others in the game scene, the system performs context recognition and action recommendation calculations in the background. At this point, if the player brings up the action interaction interface, the interface does not directly display a long list of dozens of actions. Instead, it renders the selected recommended actions "clapping" and "bowing" directly in the default focus area in the center of the screen, near where the player's thumb is hovering. Simultaneously, these actions are entirely within the first screen's visible range, allowing players to see and quickly trigger them without any swiping or page-turning operations. The entire process is smooth and natural, without interrupting the social interaction rhythm.

[0076] Optionally, the default focus area is used to indicate a pre-configured visual attention center in the graphical user interface, designed to receive trigger actions for recommended actions to achieve instant interactive responses. Optionally, the default focus area can be a pre-defined visual center location in the graphical user interface, such as the geometric center of the screen, the area surrounding the crosshair, or the operation hotspot where the player's thumb naturally hovers. Considering the movement costs of the player's eyes and fingers during gameplay, deploying recommended actions in the default focus area can significantly shorten the feedback chain from visual perception to trigger execution. The determination of this focus area can be based on parameters of various dimensions, such as adaptive calculation based on the screen size and resolution of the terminal device, or dynamic adjustment based on the historical click distribution heatmap of the target account. It should be noted that the above description of the focus area location is only one example and is not intended to limit its specific coordinates. In actual implementation, this area can also be represented as a specific slot with a highlighted border or dynamic lighting effects to further enhance the visual guidance effect, ensuring that the player can accurately locate and trigger the required recommended action the moment the interface is brought up.

[0077] Optionally, the first-screen visible area indicates the display range that the graphical user interface can be directly presented without page scrolling or page turning in the initial wake-up state. Optionally, the first-screen visible area can refer to the visible range directly mapped onto the display screen when the graphical user interface is woken up, which at least partially includes interface elements that can be directly observed by the player without swiping. To avoid social delays caused by excessively deep action list hierarchies or the need for additional page turning, the recommended actions can be directly rendered at the top layer of the first-screen visible area or in a preset instant recommendation position. In one implementation, the first-screen visible area can dynamically adjust its boundary range as the terminal device switches between portrait and landscape modes or the interface scaling ratio changes. If there are too many recommended actions and they exceed the capacity of the first-screen visible area, the system can sort them according to the priority of matching parameters, select the top target number of recommended actions for first-screen display, and collapse or hide the remaining actions in a secondary menu. It should be understood that the division logic of the first-screen visible area is not only related to the physical screen size, but also to the interface layout density of the current game stage. By limiting the core recommended content to this area, information overload can be effectively controlled, and the smoothness of interaction can be ensured.

[0078] In an optional implementation, at least one recommended action from the recommended action set is dynamically displayed in the default focus area or the first visible area of ​​the graphical user interface. This includes dynamically displaying at least one recommended action in the default focus area or the first visible area, wherein the visual style of at least one recommended action is consistent with the original visual style of the graphical user interface. By ensuring that the visual style of the recommended action is consistent with the original visual style of the graphical user interface, player resistance caused by abrupt changes in interface elements is avoided, the acceptance and willingness to use the recommendation function are improved, and the recommended action is naturally integrated into the interactive interface.

[0079] In one implementation, when a controlled virtual object encounters other virtual objects in the game scene, the system dynamically generates a recommended action icon in the visible area of ​​the first screen of the graphical user interface. This recommended action icon uses a soft color scheme and semi-transparent outline style consistent with the original game interface, rather than a high-contrast pop-up or wheel format. For example, if the original game interface is presented in a warm-toned watercolor style, the recommended action icon is also drawn with the same watercolor texture, along with consistent rounded borders and subtle shadows, making the recommended action appear as naturally as a native element of the interface, without causing a visual disconnect for the player.

[0080] Optionally, the visual style includes at least dimensions such as color parameters, line style, and transparency, to ensure that the presentation of recommended actions is consistent with the original interface elements. Optionally, the visual style can include a combination of various visual parameters such as color matching, line thickness, icon border shape, font style, and background transparency. Considering that players develop fixed visual perceptions and aesthetic habits of the interface over long-term gameplay, if the presentation of recommended actions differs too much from the original interface, it can easily trigger player resistance and reduce their willingness to use the app. Therefore, as a possible implementation, when rendering the visual elements of recommended actions, the current theme configuration file of the graphical user interface can be read to extract parameters such as primary color, secondary color, corner radius, and shadow depth, and these parameters can be applied to the drawing process of the recommended action icons. For example, when the original interface uses a low-saturation warm watercolor style, the recommended action icons should also be drawn in low-saturation warm colors with a soft watercolor-like edge effect, rather than using high-contrast solid color blocks or metallic borders. It should be noted that the above-mentioned synchronization method of visual parameters is only one example. In actual implementation, it can also be adjusted in real time according to the dynamic switching of the interface theme. This application is not intended to limit the specific synchronization method of visual style.

[0081] Optionally, besides synchronizing visual styles by reading theme configuration files, a pre-defined style template mapping approach can also be used. Specifically, during development, multiple recommended action visual templates can be pre-built, each corresponding to a different interface theme or scene atmosphere in the game. When rendering recommended actions, the system automatically matches the corresponding visual template based on the theme identifier of the current interface. For example, during a holiday event, when the interface switches to a snowflake theme, the recommended action icon synchronously loads a dedicated template with ice crystal textures; while in regular scenes, the standard template is used. Furthermore, the consistency of visual style is not only reflected in the static appearance but also extends to the dynamic performance level. That is, the duration and easing curve of the recommended action icon's appearance animation, hover feedback animation, and disappearance animation are all consistent with the animation parameters of other interactive controls in the original interface, thereby further eliminating the sense of style disconnect in the temporal dimension. It should be understood that the above template mapping and animation parameter synchronization can be used individually or in combination, depending on the interface complexity and performance budget.

[0082] The following is for reference. Figure 4 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 4 The electronic device 600 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0083] like Figure 4As shown, the electronic device 600 may include: a processor 610, a memory 620, a bus 630, an I / O (input / output) interface 640, a network adapter 650, and a display 660.

[0084] The memory 620 may include volatile memory, such as RAM 621 and cache unit 622, and may also include non-volatile memory, such as ROM 623. The memory 620 may also include one or more program modules 624, including but not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 624 may include the modules described above.

[0085] Processor 610 may include one or more processing units, such as: AP (Application Processor), modem processor, GPU (Graphics Processing Unit), ISP (Image Signal Processor), controller, encoder, decoder, DSP (Digital Signal Processor), baseband processor and / or NPU (Neural-Network Processing Unit).

[0086] The processor 610 can be used to execute executable instructions stored in the memory 620 to perform the methods described above in this disclosure.

[0087] Bus 630 is used to connect different components of electronic device 600 and may include a data bus, an address bus and a control bus.

[0088] Electronic device 600 can communicate with one or more external devices 700 (such as keyboard, mouse, external controller, etc.) through I / O interface 640.

[0089] Electronic device 600 can communicate with one or more networks via network adapter 650. For example, network adapter 650 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 650 can communicate with other modules of electronic device 600 via bus 630.

[0090] Electronic device 600 can display a graphical user interface via display 660.

[0091] although Figure 4Other hardware and / or software modules may also be configured in the electronic device 600, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

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

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

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

[0095] Although embodiments of this application 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 this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. An information processing method, characterized in that, The method includes: Obtain the current state data of the controlled virtual object corresponding to the target account, as well as the interaction state data around the controlled virtual object; Based on the current state data and the interaction state data, a set of recommended actions is determined; At least one recommended action from the recommended action set is dynamically displayed in the graphical user interface.

2. The method according to claim 1, characterized in that, The step of dynamically displaying at least one recommended action from the recommended action set in the graphical user interface includes: In response to the controlled virtual object's viewpoint crosshair aligning with the target virtual object, at least one recommended action from the recommended action set associated with the target virtual object is displayed in the graphical user interface.

3. The method according to claim 1, characterized in that, The step of determining the recommended action set based on the current state data and the interaction state data includes: Identify the current scene based on the current state data and the interaction state data; Based on the current scenario, candidate actions are evaluated to determine a set of recommended actions.

4. The method according to claim 3, characterized in that, The step of evaluating candidate actions based on the current scenario to determine a recommended action set includes: Based on the current state data and the interaction state data, determine the matching parameters between the candidate action and the current scene; Based on the matching parameters, a set of recommended actions is obtained by filtering from the candidate actions.

5. The method according to claim 4, characterized in that, The step of filtering the candidate actions to obtain a set of recommended actions based on the matching parameters includes: Acquire group action trend data, which includes the server-wide usage frequency of each candidate action within a preset time period; Based on the overall usage frequency across the server, determine the popularity weight value for each candidate action; Based on the matching parameters and the popularity weight value, a set of recommended actions is obtained by filtering from the candidate actions.

6. The method according to claim 4, characterized in that, The step of filtering the candidate actions to obtain a set of recommended actions based on the matching parameters includes: Obtain the historical social preference data of the target account, which includes the frequency of use and / or usage scenario records of each candidate action in the historical interactions of the target account; Based on the historical social preference data, determine the personalized weight value of each candidate action; Based on the matching parameters and the personalized weight values, a set of recommended actions is obtained by filtering from the candidate actions.

7. The method according to claim 4, characterized in that, The step of filtering the candidate actions to obtain a set of recommended actions based on the matching parameters includes: Acquire group action trend data and the target account's historical social preference data; The popularity weight value of each candidate action is determined based on the group action trend data, and the personalized weight value of each candidate action is determined based on the historical social preference data. Based on the matching parameters, the popularity weight value, and the personalization weight value, a set of recommended actions is obtained by filtering from the candidate actions.

8. The method according to claim 1, characterized in that, The method further includes: The system detects preset events, which include at least one of the following: receiving an interaction request initiated by another virtual object, detecting that the controlled virtual object enters a designated area, or detecting that the distance between the controlled virtual object and the target virtual object is less than a distance threshold. In response to the detection of the preset event, the set of recommended actions is updated.

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

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, are used to implement the information processing method as described in any one of claims 1 to 8.

Images