Information processing method and device, electronic equipment and computer readable storage medium

Abstract

An embodiment of the present disclosure provides an information processing method, comprising: establishing a collaborative browsing session between a first virtual character and at least one second virtual character, the first virtual character being controlled by a current terminal, and the second virtual character including a virtual character controlled by a second terminal and / or a non-controlled virtual character; monitoring a behavior state of the first virtual character and / or the second virtual character, the behavior state including at least a browsing state and a non-browsing state; and determining a display form of a first window and / or a second window provided by a graphical user interface of the current terminal according to the behavior state, wherein the first window is used to display browsing content of the first virtual character in the browsing state, and the second window is used to display browsing content of the second virtual character in the browsing state or behavior state information of the second virtual character according to the behavior state of the second virtual character.

Description

Technical Field

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

[0002] In virtual environments that support multiplayer online interaction, virtual item trading is a common interactive function. Existing solutions typically display virtual item information through a separate interface that occupies the full-screen display area of ​​the terminal. When users need to perform other interactive actions such as combat or forming a party, they often have to manually exit the current browsing interface, thus forcibly interrupting their attention to the browsing content.

[0003] However, the above solutions mainly display browsing content in a fixed window layout. When users perform other interactive behaviors, they need to frequently switch or rebuild the display interface manually. The operation is cumbersome and generates a large number of redundant interface switching commands, which increases the load on terminal graphics rendering and data processing. In multi-task parallel scenarios, the efficiency of interface resource utilization is low. Summary of the Invention

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

[0005] According to one aspect of this disclosure, an information processing method is provided, the method comprising: establishing a collaborative browsing session between a first virtual character and at least one second virtual character, wherein the first virtual character is controlled by a current terminal, and the second virtual character includes a virtual character controlled by a second terminal and / or an uncontrolled virtual character; monitoring the behavioral state of the first virtual character and / or the second virtual character, wherein the behavioral state includes at least a browsing state and a non-browsing state; and determining, based on the behavioral state, the display format of a first window and / or a second window provided by the graphical user interface of the current terminal, wherein the first window is used to display browsing content of the first virtual character in the browsing state, and the second window is used to display browsing content or behavioral state information of the second virtual character in the browsing state according to the behavioral state of the second virtual character.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, comprising: a session establishment module for establishing a collaborative browsing session between a first virtual character and at least one second virtual character, wherein the first virtual character is controlled by a current terminal, and the second virtual character includes a virtual character controlled by a second terminal and / or an uncontrolled virtual character; a behavior monitoring module for monitoring the behavior state of the first virtual character and / or the second virtual character, wherein the behavior state includes at least a browsing state and a non-browsing state; and a display control module for determining, based on the behavior state, the display format of a first window and / or a second window provided by the graphical user interface of the current terminal, wherein the first window is used to display browsing content of the first virtual character in the browsing state, and the second window is used to display browsing content or behavior state information of the second virtual character in the browsing state based on the behavior state of the second virtual character.

[0007] According to one aspect of this disclosure, an electronic device is provided, comprising: a memory storing computer-executable instructions executable by a processor; and a processor for executing the computer-executable instructions to implement any of the above methods.

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

[0009] The technical solution provided in this disclosure establishes a collaborative browsing session and dynamically monitors the behavioral status of all participating parties. This enables the current terminal to adaptively switch the display form of the first window and / or the second window on the graphical user interface based on the real-time browsing and non-browsing behavior status of the first and second virtual characters. This allows players to continuously access browsing content shared by the second virtual character or its status prompts through the persistent, dynamically changing second window when they are unable to focus on browsing due to the first virtual character performing other non-browsing behaviors. This eliminates the need to interrupt and rebuild the browsing scene, effectively reducing the data processing pressure and resource consumption caused by the frequent loading and rendering of product interfaces on the terminal. At the same time, it significantly simplifies the operation process for players to perform multi-task parallel processing and improves the efficiency of human-computer interaction. Attached Figure Description

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

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

[0012] Figure 2 A flowchart illustrating a method in one exemplary embodiment of this disclosure is shown; Figure 3 A schematic diagram illustrating a graphical user interface displaying a collaborative browsing entry point in one exemplary embodiment of this disclosure; Figure 4 A schematic diagram illustrating a graphical user interface for displaying a collaborative browsing request in one exemplary embodiment of this disclosure; Figure 5 A schematic diagram illustrating a first display style and a second display style of the collaborative browsing entry in one exemplary embodiment of this disclosure; Figure 6 A schematic diagram of a graphical user interface in dual browsing state is shown in one exemplary embodiment of this disclosure; Figure 7 This diagram illustrates a graphical user interface for a window adjustment control in a dual-browsing state according to one exemplary embodiment of the present disclosure. Figure 8 A schematic diagram showing a filter setting interface in one exemplary embodiment of this disclosure; Figure 9 This diagram illustrates a graphical user interface showing a first virtual character in a non-browsing state in one exemplary embodiment of the present disclosure. Figure 10 A schematic diagram showing a graphical user interface in which the second window is hidden in one exemplary embodiment of the present disclosure; Figure 11 This diagram illustrates a graphical user interface showing a prompt message in a hidden state in one exemplary embodiment of the present disclosure. Figure 12 This diagram illustrates a graphical user interface in a second window indicating the detection of a target virtual item in one exemplary embodiment of the present disclosure; Figure 13 This diagram illustrates a graphical user interface of a second virtual character in a non-browsing state according to one exemplary embodiment of the present disclosure. Figure 14 This diagram illustrates a device structure according to one exemplary embodiment of the present disclosure. Figure 15 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

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

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure 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 disclosure 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.

[0015] The accompanying drawings are schematic illustrations of this disclosure 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 disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0016] Figure 1A 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 application services 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 disclosure can be executed by any one or more of the terminal device 110 and the server 120.

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

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

[0019] Information processing method according to one embodiment of this disclosure, such as Figure 2 As shown, the method may include: Step S210: Establish a collaborative browsing session between a first virtual character and at least one second virtual character. The first virtual character is controlled by the current terminal, and the second virtual character includes a virtual character controlled by the second terminal and / or an uncontrolled virtual character. Step S220: Monitor the behavior status of the first virtual character and / or the second virtual character, including at least the browsing status and the non-browsing status; Step S230: Based on the behavior state, determine the display format of the first window and / or the second window provided by the graphical user interface of the current terminal, wherein the first window is used to display the browsing content of the first virtual character in the browsing state, and the second window is used to display the browsing content or behavior state information of the second virtual character in the browsing state according to the behavior state of the second virtual character.

[0020] The method provided in this embodiment allows players to continuously access browsing content or behavioral status information shared by the second virtual character through a dynamically changing second window even when they are engaged in other game activities and cannot focus on browsing. This eliminates the need to interrupt and rebuild the browsing scene, reducing terminal processing resource consumption caused by repeated interface switching and reloading, improving the interactive experience, enriching in-game cooperative gameplay, and enhancing the game's richness. Further description of this embodiment follows.

[0021] In step S210, a collaborative browsing session is established between a first virtual character and at least one second virtual character. The first virtual character is controlled by the current terminal, and the second virtual characters include virtual characters controlled by a second terminal and / or uncontrolled virtual characters. By establishing a collaborative browsing session, multiple virtual characters can synchronously share browsing content, achieving not only real-time information exchange across terminals but also supporting collaborative browsing between players and other players or uncontrolled virtual characters, effectively improving the flexibility and efficiency of gameplay.

[0022] Optionally, collaborative browsing sessions are used to establish content-sharing channels between multiple virtual characters, synchronously transmitting corresponding browsing data and interaction commands.

[0023] Optionally, the collaborative browsing session can be a real-time data channel established based on a network server relay. During this session, the browsing scene information of the first and second virtual characters is synchronously forwarded through the server. For example, when the second virtual character stops to view a specific virtual item at a stall, the viewed content (including the item icon, name, attributes, and price) is pushed in real time to the current terminal corresponding to the first virtual character via the session channel, causing a second window to appear in the first virtual character's graphical user interface to display the content. The establishment process of this session may include authentication, permission verification, and encrypted data transmission to ensure the security and consistency of the viewed content during multi-party interaction. It should be noted that the duration of the above session can be set according to the player's needs to continue until either party actively terminates it or a preset termination condition is met. For example, in temporary mode, the session is automatically disconnected when the character leaves the trading area, while in continuous mode, the session remains until either party manually exits.

[0024] Optionally, the first virtual character is a digital avatar controlled by the current end-user in the game world, which performs browsing operations within the virtual trading area. The first virtual character can have various appearances, such as humanoid, animal-like, or custom-designed forms. The first virtual character's behaviors in browsing mode include moving the browsing viewpoint, clicking on virtual items to view details, and performing purchase operations. The first virtual character has the ability to browse virtual goods or virtual content in the virtual environment. When the first virtual character enters browsing mode, the browsing content corresponding to its browsing operations is presented on the current terminal's graphical user interface through a first window. For example, when the first virtual character views virtual items displayed on virtual stalls one by one in a virtual market, the first window can display details of the stall being viewed; as another example, when the first virtual character browses the item catalog in a virtual auction house, the first window can present item illustrations and attribute descriptions; and yet another example, when the first virtual character previews a custom appearance scheme in a virtual workshop, the first window can display a real-time rendered 3D preview. The first virtual character's behavioral data is collected by the current terminal and transmitted to the server via the network. The server then distributes this data to other participants in the collaborative browsing session.

[0025] Optionally, a second virtual character refers to one or more other virtual characters, besides the first virtual character, participating in the collaborative browsing session. The second virtual character can be a virtual character controlled by another terminal (i.e., a virtual character controlled by the second terminal), or it can be an uncontrolled virtual character (e.g., an NPC) automatically controlled by the system. For a second virtual character controlled by a second terminal, its behavior is determined by other operators, and the browsing content and behavior status information are transmitted over the network to the first virtual character's current terminal. Uncontrolled virtual characters are driven by the system according to preset logic, and their browsing behavior and status changes are simulated and generated by the server. For example, the second virtual character might be a virtual character controlled by another player in the friend list, browsing stalls in a virtual market; or it might be a fixed NPC merchant in a guild, patrolling the stall area according to a system-set route; or it might be multiple friend virtual characters controlled by multiple terminals, with each friend's browsing content displayed through their respective second window. It should be noted that uncontrolled virtual characters can also be characters controlled by friends offline through a hosting service.

[0026] In an optional implementation, establishing a collaborative browsing session between a first virtual character and at least one second virtual character includes: in response to detecting at least one second virtual character that meets preset collaborative conditions, establishing a collaborative browsing session between the first virtual character and at least one second virtual character. Thus, by introducing a detection mechanism for preset collaborative conditions before establishing a collaborative browsing session, it ensures that both parties in the session meet specific association conditions or regional constraints, effectively filtering invalid connection requests, improving the accuracy of session establishment, and reducing system resource consumption.

[0027] Optionally, preset collaboration conditions refer to a set of criteria pre-configured by the system to determine whether two virtual characters are suitable for establishing a collaborative browsing session. A preset collaboration condition can be a single condition or a logical combination of multiple conditions (e.g., AND or OR combinations). If all necessary items in the preset collaboration conditions are met between the first virtual character and the target second virtual character, the system determines the second virtual character as a candidate for establishing a collaborative browsing session. The preset collaboration conditions can be defined based on dimensions such as the spatial location relationship of virtual characters, social relationship data, historical behavior data, character level conditions, online status conditions, or task progress conditions. For example, a preset collaboration condition might be that the distance between the first and second virtual characters is less than a preset threshold, allowing a session to be established when the two virtual characters are detected to be sufficiently close in the virtual space; another example is that the preset collaboration conditions include the first and second virtual characters being in a specified virtual scene type; yet another example is that the preset collaboration conditions require both to have a preset social relationship chain and be online simultaneously, and session establishment is not triggered if they are not online simultaneously.

[0028] Optionally, a friend number threshold can be set in the preset collaboration conditions. When the number of second virtual characters that meet the conditions exceeds the threshold, the system can further filter out the top N characters by priority (e.g., by historical collaboration frequency, recent interaction time, character attribute matching degree, etc.) to avoid creating too many collaborative browsing sessions at once, which would lead to too many interface elements and affect terminal rendering performance. For example, when the preset collaboration conditions match 15 candidate second virtual characters, the terminal selects only the top 5 by recent interaction time to establish a session; another example is that the terminal selects the top 3 by sorting the characters' intimacy values ​​from high to low; yet another example is that the system prioritizes selecting second virtual characters that are in the same friend group as the first virtual character.

[0029] Optionally, a detection mechanism based on preset collaborative conditions is used to screen and determine the conditions of candidate roles in the virtual scene before initiating the collaborative browsing session establishment process.

[0030] Optionally, this detection mechanism can be implemented through periodic polling, where the system scans other virtual characters within a certain range around the first virtual character at preset time intervals (e.g., every 0.5 seconds or every 1 second), comparing them one by one to see if they meet the preset collaboration conditions. Alternatively, this detection mechanism can be implemented through an event-driven approach, such as triggering a full scan when the first virtual character enters a preset virtual transaction area, or triggering targeted detection when a second virtual character goes online or enters the same scene. It should be noted that the detection can be performed locally on the client and then reported to the server for verification, or it can be centrally executed on the server and the results pushed to the current terminal. When multiple second virtual characters meet the conditions, the system can display candidate character identifiers in a list on the graphical user interface for selection; if only one second virtual character meets the conditions, the system can directly send a request or pop up a confirmation dialog box. Whether automatically triggered or manually confirmed, this mechanism ensures that session establishment is object-oriented and scene-adaptive, avoiding invalid interactions caused by blind invitations.

[0031] In an optional implementation, the preset collaboration conditions include: both the first virtual character and the second virtual character are located within a preset virtual trading area; and / or, the first virtual character and the second virtual character have a social connection. Thus, by limiting the activity through both spatial area and social relationship, the rationality and scenario-specificity of collaborative browsing are ensured, while preventing unrelated characters from arbitrarily triggering conversations and causing interface chaos, thereby improving the accuracy of conversation establishment and the user experience.

[0032] For example, after the player's first virtual character enters the central marketplace area within the game, the terminal detects that second virtual characters A, B, and C, who are friends with the first virtual character, are also simultaneously in the same marketplace area. At this point, the first virtual character and the second virtual characters A, B, and C all meet the preset collaborative conditions of being located within a preset virtual trading area and having a social connection. The terminal displays a prompt on the interface indicating that a collaborative browsing session can be established, and the player can select all or some of the second virtual characters to establish a collaborative browsing session. Furthermore, the aforementioned social dimension constraint can be further limited to mutual friends with a specified intimacy level to ensure that the collaborative browsing partners have a sufficient foundation of trust.

[0033] Optionally, a preset virtual trading area is used to define the spatial range within which virtual characters can initiate collaborative browsing. This area includes at least stall scenes and market scenes. Optionally, the preset virtual trading area can be a centralized area in the game world specifically for trading virtual items. This area can be a closed virtual building (e.g., a virtual shop, auction house lobby), an open virtual area (e.g., an open-air market, free stall area), or a logical area corresponding to a specific functional interface (e.g., opening the trading panel is considered entering the trading area). This area is marked on the game map with a specific icon or boundary line. When the first or second virtual character enters the boundary of this area, the system triggers location detection logic. Considering that the collaborative browsing function needs to be based on actual trading scenarios to realize its core value of convenient stall browsing, binding the preset collaborative conditions to a specific spatial area can effectively filter out invalid session requests in non-trading scenarios. In actual presentation, the boundary of this area can be a visible decorative fence, a ground glowing effect, or an invisible but detectable coordinate range in the system backend. As long as the spatial coordinates of the first and second virtual characters both fall within this preset range, it is considered that the area collaborative conditions are met.

[0034] Optionally, the determination logic for the preset virtual trading area can be based on whether the character's center point coordinates fall within the area polygon, or on the degree of overlap between the character's collider and the area trigger. This embodiment does not limit this approach. Furthermore, the area coordination condition is confirmed to be met only when the first virtual character and the second virtual character remain within the preset virtual trading area for a specified duration, or when the distance between them is within a preset threshold and both are within the trading area. It should be noted that the specified duration and preset threshold are related not only to server load and network latency, but also to the player density and trading activity in the current virtual trading area. The system can dynamically adjust the parameters accordingly to ensure accuracy while balancing response sensitivity and server processing overhead.

[0035] Optionally, social connections are used to represent the pre-defined binding relationship between the first and second virtual characters, including but not limited to friend relationships, master-apprentice relationships, guild / faction member relationships, team / team relationships, and spouse / sworn brotherhood relationships. Besides using the game's built-in friend system, the system can also receive manually entered character identifiers from players to establish temporary collaborative relationships, or verify cross-platform friend identities through third-party social platform account binding; this disclosure is not limited to these. To avoid malicious interference or information overload from unrelated characters, making social connections a necessary component of pre-defined collaborative conditions ensures that collaborative browsing sessions are only established between players who have established basic trust or a willingness to cooperate, thereby guaranteeing information security and interactive comfort during virtual item transactions.

[0036] Optionally, the verification process for social connections can be completed in real time on the server side. When the first virtual character enters the preset virtual trading area, the server queries its social graph and filters out candidate second virtual characters that simultaneously meet the area conditions and connection requirements. The status of this connection can dynamically change based on the player's social actions. For example, when the second virtual character removes the first virtual character from the friend list, even if both are still in the same virtual trading area, the system will immediately update the collaboration condition judgment result and remove the first virtual character from the list of inviteable characters. It should be noted that, in addition to the basic relationship type identifier, the aforementioned social connections can also be accompanied by additional attributes such as intimacy level, recent team-up frequency, or historical transaction records. Based on this, the system can prioritize candidate second virtual characters or use these additional attributes as further filtering conditions, prioritizing the display of friends with higher intimacy levels near the collaboration browsing entrance or removing friends with lower intimacy levels from the list of inviteable characters. This allows players to quickly locate the target characters they wish to collaborate with, reducing the operational cost of searching through multiple candidate characters one by one.

[0037] Optionally, the preset collaboration conditions, including the regional condition and the social relationship condition, can be combined using either AND (both conditions must be met) or OR (either one is sufficient). The specific combination of these logics can be preset by the system or customized by the operator of the first virtual character. When making a judgment, the terminal or server combines the results of the two conditions according to the configured logical operators. For example, the system defaults to AND logic: the second virtual character is considered a candidate that meets the preset collaboration conditions only if the first virtual character and the second virtual character are both located in the same preset virtual transaction area and have a social relationship. Alternatively, when OR logic is used, a collaborative browsing session can be established as long as the two characters are in the same transaction area, even without a social relationship (suitable for temporary collaborative browsing between strangers). Furthermore, the operator can switch between AND and / or logic configurations in the settings interface to adapt to different usage scenarios.

[0038] In an optional implementation, establishing a collaborative browsing session between the first and second virtual characters includes: displaying a collaborative browsing entry on the graphical user interface of the current terminal; sending a collaborative browsing request to the second terminal in response to a trigger operation on the collaborative browsing entry; and establishing a collaborative browsing session between the first and second virtual characters in response to receiving a confirmation reply from the second terminal. Thus, by providing a collaborative browsing entry on the graphical user interface of the current terminal and establishing the session through a trigger operation and confirmation reply, the process of creating a collaborative browsing session becomes more intuitive and convenient, effectively improving session establishment efficiency and player interaction experience.

[0039] In one implementation, see Figure 3 and Figure 4 When the first virtual character enters the preset virtual trading area, the system scans other virtual characters within that area in real time. If a second virtual character with a social connection to the first virtual character and also located within the area is detected, the preset collaboration conditions are met, triggering the display of a collaborative browsing entry on the current terminal's graphical user interface. Players click this entry to trigger the action, and the current terminal immediately sends a collaborative browsing request to the second terminal. Upon receiving the request, the second terminal displays a pop-up window with agree and disagree options. When the player on the second virtual character's side agrees, the second terminal sends a confirmation reply to the current terminal, thus establishing a collaborative browsing session between the first and second virtual characters, allowing both to simultaneously browse stalls.

[0040] Optionally, the collaborative browsing entry refers to an interactive interface element provided on the graphical user interface of the current terminal, used to guide the operator of the first virtual character to initiate the collaborative browsing session establishment process. The visual form of the collaborative browsing entry can be various, such as a button, icon, floating label, or shortcut menu item. The display position of the collaborative browsing entry can be fixed in a specific area of ​​the interface (e.g., sidebar, top toolbar), or it can dynamically change with the current position of the virtual character (e.g., appearing when the virtual character approaches other characters), or it can be conditionally displayed based on the detected information of the second virtual character (e.g., displaying the entry when preset collaborative conditions are met). For example, the collaborative browsing entry could be a button in the upper right corner of the graphical user interface, displaying an icon for browsing friend stalls and the number of currently available friends for collaboration; another example is that when the first virtual character approaches a friend's virtual character, a clickable collaborative browsing invitation bubble appears above the friend's head; yet another example is that in the friend list interface, a collaborative browsing shortcut icon is added to the right of each online friend entry. The above descriptions of entry styles and positions are merely examples, and this disclosure is not intended to limit them.

[0041] Optionally, considering that a large number of players may be active simultaneously in the virtual trading area, to avoid the collaborative browsing entrance from continuously flashing or frequently popping up and interfering with players' normal operations, the display of the aforementioned collaborative browsing entrance can also be combined with a preset do-not-disturb mode or intelligent filtering strategy. For example, when the first virtual character and the second virtual character are located in the same preset virtual trading area, but both of their current behavior states are in a non-browsing state, the system can temporarily suppress the pop-up of the collaborative browsing entrance or keep it in a collapsed state until either party enters a browsing state before presenting it. One objective of this embodiment is that by introducing a state prediction mechanism at the entrance, on the one hand, unnecessary interface elements occupying screen space can be reduced, and on the other hand, the probability of invalid request sending due to accidental touches can be reduced, making the session establishment process more in line with the actual operational needs of players.

[0042] Optionally, the collaborative browsing request is used to send a session establishment signal to the second terminal after the current terminal confirms the player's triggering operation on the collaborative browsing entry, so as to start the process of establishing a collaborative browsing session between the first virtual character and the second virtual character.

[0043] Optionally, the process of sending a collaborative browsing request to the second terminal can be through message relay via the server or through direct communication between the terminals. In one possible implementation, the request can be pushed to the second terminal in the form of an instant message, or it can be integrated into the in-game friend interaction channel and broadcast as a special event. The message content of the collaborative browsing request may include the identification information of the first virtual character, browsing context information (such as the current region, browsing type, etc.), and the validity period of the request. For example, when the first virtual character clicks the collaborative browsing entry and selects a target friend, the terminal generates a message containing the first virtual character ID, the current marketplace name, and the request timestamp, and pushes it to the friend's second terminal via the server. It should be noted that the timing of sending the collaborative browsing request, in addition to being sent immediately after the collaborative browsing entry is triggered, can also include a short delay buffer window; for example, after the system detects the trigger operation, it waits for a preset time. If the player does not cancel the action within this period, the request is officially sent to the second terminal, thus providing the player with some room for accidental reversal.

[0044] Optionally, a confirmation reply refers to the response message given by the operator of the second terminal after receiving the collaborative browsing request. The confirmation reply can be agreement (confirmation of participation in collaborative browsing), rejection (non-participation in collaborative browsing), or no response after timeout (default is rejection). If agreement is granted, a session is established and data synchronization begins; if rejection is granted, a rejection prompt is returned to the first virtual character so that the current terminal can perform corresponding follow-up processing based on the rejection prompt. On the second terminal side, upon receiving the collaborative browsing request, a confirmation window containing agreement and rejection controls can pop up on its graphical user interface. This confirmation window can be displayed in the center as a modal dialog box or slide out from the edge of the interface as a small notification. Furthermore, to avoid players blocking the waiting process on the first virtual character side for an extended period due to not promptly noticing the request, a countdown mechanism can be introduced into the above confirmation reply generation process; for example, if the second terminal does not return any reply within a preset waiting time, the current terminal can default to rejection or automatically cancel the session establishment process and notify the first virtual character that the invitation has timed out. It should be understood that the specific duration of the above countdown mechanism can be configured according to different scenarios, such as setting it to ten seconds in ordinary leisure scenarios and five seconds in competitive scenarios. This disclosure does not limit this.

[0045] In an optional implementation, the collaborative browsing entry includes a first display style and a second display style. When no second virtual character meeting the preset collaboration conditions is detected, the collaborative browsing entry displays in the first display style. When at least one second virtual character meeting the preset collaboration conditions is detected, the collaborative browsing entry displays in the second display style, which includes displaying the number of second virtual characters meeting the preset collaboration conditions. In this way, the collaborative browsing entry intuitively reflects the presence and number of nearby collaborative objects through style differences, facilitating players to quickly identify team-up feasibility, reducing the interaction cost of ineffective searches, and improving browsing efficiency.

[0046] For example, see Figure 5 When a player controlling the first virtual character enters the designated market area, if no online friends with social connections are found within the area, the collaborative browsing entry will be displayed in the first style, such as a dimmed button that is not interactive. If three qualified second virtual characters subsequently enter the area, the system will immediately switch the entry to the second display style, such as displaying a bright "3" superimposed on the button with a highlight effect. Upon observing this visual change, players will clearly know that there are nearby friends to invite, and can directly click the entry to initiate a collaborative browsing request to the corresponding friend.

[0047] The first display style represents the visual state of the collaborative browsing entry when no second virtual character meeting the preset collaborative conditions is detected. Optionally, the first display style aims to convey to the player that there is currently no target object available for collaborative browsing in the scene, and its visual expression can be diverse. As one possible implementation, the first display style can reduce the overall transparency of the collaborative browsing entry to a preset ratio, or adjust its button color to a dark gray tone to create a significant contrast with regular interactive controls. Furthermore, to avoid accidental touches by players due to the button still occupying the interface space, the first display style can also include interactive feedback for a disabled state, such as overlaying a miniature lock icon on the entry, or providing a visual jitter prompt when the player attempts to click instead of triggering any jump. It should be noted that the specific rendering parameters of the above-mentioned first display style can be dynamically graded according to the terminal's graphics performance. For example, a delicate fading animation can be presented on high-performance devices, while a static low-contrast texture can be directly switched on performance-limited devices.

[0048] The second display style is used to indicate the visual state of the collaborative browsing entry when a second virtual character meeting preset collaborative conditions is detected, and includes information on the number of collaborative objects. The second display style is used to attract the operator's attention and prompt them to perform collaborative browsing operations. It needs to create a visual contrast with the first display style, including but not limited to highlighted colors, dynamic lighting effects, and overlaid numerical badges. In addition to restoring the collaborative browsing entry to its usual clickable bright color, the second display style can further add dynamic visual elements, such as a flowing light marquee around the button's edge, periodic micro-scaling breathing animations, or a gradual light effect from dark to light, thereby establishing stronger salience at the level of human visual capture. Simultaneously, the second display style needs to carry quantitative information, which can be presented as compact Arabic numeral badges floating in the top corner area of ​​the entry button, as a dot badge overlaid with numbers, or as a miniature counting plaque embedded within the button itself. It should be noted that the refresh logic of the above-mentioned badges or nameplates can be consistent with the scene detection thread of the server or client. When a change in the number of second virtual characters that meet the preset collaboration conditions is detected, the quantity indicator is increased or decreased in real time. If the value returns to zero, it will automatically revert to the first display style, thereby ensuring a real-time closed loop of status feedback.

[0049] In an optional implementation, in response to a trigger operation on the collaborative browsing entry point, a collaborative browsing request is sent to the second terminal, including: in response to a trigger operation on the collaborative browsing entry point, displaying multiple second virtual character identifiers that meet preset collaborative conditions; and in response to a trigger operation on any second virtual character identifier, sending a collaborative browsing request to the second terminal corresponding to the selected second virtual character identifier. Thus, when multiple second virtual characters that meet the preset collaborative conditions exist, they are first presented as a list of character identifiers for the operator of the first virtual character to select from, and then the request is sent to the selected target character. This avoids unnecessary message pushes to unrelated character terminals, reduces network data transmission volume, and decreases the processing overhead of invalid messages by non-target terminals.

[0050] In one implementation, when the first virtual character moves to a stall area where multiple friends are present, the collaborative browsing entry on the graphical user interface becomes triggerable. After the player clicks this entry, a vertically arranged semi-transparent floating window appears in the center of the interface, listing the avatars and nicknames of three friends who meet preset collaboration criteria, serving as identifiers for multiple second virtual characters. The player then clicks on the identifier corresponding to the second avatar, and the terminal immediately sends a collaborative browsing request to the second terminal logged into by that friend, awaiting confirmation from the other party.

[0051] Optionally, the second virtual character identifier is used to present candidate objects that meet preset collaboration conditions in a distinguishable form within the graphical user interface, allowing the controller of the first virtual character to identify and select them. This identifier is not limited to a static character avatar or text nickname; it may also include additional information such as the character's online status, current channel, or intimacy level. This disclosure is not intended to limit this. In one possible display format, multiple second virtual character identifiers are arranged in a vertical list within a semi-transparent floating window, with each identifier occupying an independent touch area, distinguished from each other by dividing lines or background color differences. In another possible display format, the identifiers may also be displayed in a grid matrix or presented sequentially as horizontally sliding cards. It should be noted that if a second virtual character that meets the preset collaboration conditions exists, the list may still display a single identifier, or the list display may be skipped and a collaboration browsing request sent to that object; the specific implementation can be adaptively adjusted according to system configuration or player preferences.

[0052] Optionally, considering that the number of second virtual characters meeting the preset collaboration conditions may be large in actual application scenarios, to avoid players blindly searching through lengthy lists, the aforementioned multiple second virtual character identifiers can be sorted or grouped according to predetermined rules before or during display. For example, the identifier list can be arranged from highest to lowest friend intimacy, or from closest to furthest distance between the character and the first virtual character in the virtual scene, or friends with recent trading interactions can be pinned to the top. Furthermore, the list area can be configured with a search control, allowing players to quickly narrow down the display by entering part of the character's nickname. If some second virtual characters are in combat or have enabled do-not-disturb mode, their corresponding identifiers can be displayed in gray or have an unclickable status label overlaid on them, thus indicating to the player that a collaborative browsing request cannot be sent to that object at this time; this disclosure does not limit this.

[0053] Optionally, triggering the second virtual character identifier typically involves the player tapping the target identifier on the graphical user interface. Considering the potential risk of accidental touches on mobile devices, as a possible implementation, the triggering operation can also be configured as a confirmation response after a sustained press for a certain duration, or as applying enlarged and highlighted visual feedback to the target identifier after clicking and waiting for secondary confirmation. After the player triggers the confirmation button a second time, the terminal sends a collaborative browsing request to the corresponding second terminal. In another implementation, to improve operational efficiency, two-finger taps or single taps can be considered confirmation and a request sent immediately. Different confirmation strengths can be dynamically adapted based on the size of the identifier or the player's historical operating habits; this disclosure does not limit this.

[0054] In an optional implementation, the method further includes: in response to selecting multiple second virtual character identifiers, sending collaborative browsing requests to multiple second terminals corresponding to the selected multiple second virtual character identifiers; in response to receiving confirmation responses from the multiple second terminals, establishing a collaborative browsing session between the first virtual character and the multiple second virtual characters; the second window includes multiple instances, wherein each second window is used to display the browsing content of the corresponding second virtual character in the browsing state. This not only expands the social boundaries of collaborative browsing but also allows players to simultaneously monitor the browsing activities of multiple friends, thereby significantly improving the retrieval efficiency of target items and the reach of information.

[0055] In one example, when Player A triggers the collaborative browsing entry in the market area, a list of eligible friends within the current stall area pops up. Player A selects both Player B and Player C's avatars using a checkbox, and the system immediately sends collaborative browsing requests to both friends' respective devices. After both Player B and Player C confirm their agreement, two parallel second windows are generated in Player A's graphical user interface. The left window displays Player B's current equipment and item inventory in real time, while the right window displays Player C's current consumable inventory. Player A can directly click on items in either window to view details or make a purchase.

[0056] Optionally, multiple second windows can be set, each suitable for independently displaying the browsing content of the corresponding second virtual character in browsing mode. Optionally, when a collaborative browsing session is successfully established and multiple second virtual characters are involved, multiple second windows can be simultaneously presented in the graphical user interface of the current terminal. The number of these multiple second windows corresponds to the number of second virtual characters participating in collaborative browsing. The display area occupied by each second window in the interface can be allocated by the system by default, such as being evenly divided according to the number of participants, or the first virtual character can manually adjust the display area ratio of each window by dragging the boundary lines. It should be noted that each second window independently loads and renders the real-time browsing content of the corresponding second virtual character. The data stream it loads comes from the browsing status snapshots or real-time screen streams periodically reported by the corresponding second terminal. To prevent performance overload caused by parallel rendering of multiple windows, the above-mentioned multiple second windows can share the same network connection channel for data reception in the background, but maintain their own independent view containers and interactive response areas at the front-end presentation level. This ensures the smoothness of multi-window collaborative browsing and allows the first virtual character to keep track of the browsing dynamics of multiple friends at any time without interrupting its current game behavior.

[0057] Optionally, the layout of multiple second windows in the graphical user interface can be arranged in various ways, such as vertical stacking, horizontal side-by-side, grid arrangement, or cascading (supporting tab switching). The terminal can dynamically adjust the layout according to the number of second windows and the content type of each window to ensure the readability and ease of operation of the interface. When the number of second windows exceeds the interface's capacity limit, the terminal can provide mechanisms such as scrolling, page turning, or collapsing / expanding. For example, when there are two second windows, they occupy the bottom area of ​​the interface in a horizontally even manner; when there are five second windows, they are arranged in a vertically scrolling list on the right side of the interface, with each window displaying a thumbnail preview of the content; as another example, when there are more than three second windows, the extra windows are automatically collapsed into a tab bar, and the operator can expand the corresponding second window by clicking the tab; as yet another example, the terminal can automatically place the most frequently updated window at the top or in the largest size position according to the update frequency of the content browsed by each second virtual character.

[0058] Optionally, the selection of multiple second virtual character icons can take various specific interactive forms. For example, the selection operation could involve sequentially clicking on multiple friend avatar icons marked with checkboxes, and triggering a unified confirmation control after all are selected, thereby sending collaborative browsing requests in batches to the second terminals corresponding to all selected second virtual characters. In another implementation, users can long-press and swipe across multiple second virtual character icons in the friend list area to form a batch selection area. After releasing the long-press, the system automatically identifies all friends included in the area and initiates batch invitations. In yet another implementation, after selecting a second virtual character icon and sending a request, users can select and request other second virtual character icons at any time to increase the number of participants in collaborative browsing.

[0059] Optionally, after receiving confirmation responses from each second terminal, the terminal can perform corresponding processing based on the response type. For second terminals that agree, a session is established with them and a corresponding second window is assigned to display the synchronization data. For second terminals that refuse, a rejection prompt can be displayed to notify the player.

[0060] In step S220, the behavioral state of the first virtual character and / or the second virtual character is monitored, including at least a browsing state and a non-browsing state. This continuous monitoring of the virtual character's behavioral state provides an accurate triggering benchmark for dynamic window mode switching, ensuring that the interface display is synchronized in real-time with the player's actual operation.

[0061] Among them, behavioral state is used to characterize the interaction mode of the virtual character in the virtual trading scenario, serving as the basis for determining window mode switching. Optionally, the above behavioral state can be browsing state, non-browsing state, and other subdivided intermediate states. This behavioral state can be directly recorded in the terminal's local cache, or it can be centrally maintained by the server and sent to the other end of the collaborative session in real time. Specifically, the browsing state is the state when the virtual character is viewing virtual item information in the virtual trading area. In the browsing state, the virtual character can perform various browsing operations, including: moving the browsing view to view different stalls, clicking on virtual items to view detailed attributes, adding virtual items to the watchlist, and performing a purchase operation. The data of the browsing state can include the currently viewed stall identifier, the list of viewed virtual items, browsing duration, etc.; the non-browsing state covers all other scenario states where the virtual character is not currently in the stall browsing interface, such as being in a combat instance, moving on the world map, in the system settings interface, or in the social team interface, etc. It should be noted that the above description of the state types is only one example and is not intended to limit the composition of behavioral states.

[0062] Optionally, the specific logic for determining the behavior state can be based on at least one of the following: the scene instance number where the virtual character is currently located, the top-level active window identifier in the graphical user interface, and the interaction protocol type most recently triggered by the virtual character. For example, during local monitoring on the client side, the behavior state of the virtual character can be determined by listening to the top-level active window identifier in the graphical user interface. When the current top-level window is detected as a booth browsing panel, the behavior state of the local virtual character is set to browsing state; otherwise, it is set to non-browsing state. During server-side determination, the server can perform state mapping based on the scene instance number where the virtual character is currently located and the interaction protocol type it triggered. For example, when a protocol request to open a booth is received from the virtual character, its state is marked as browsing state; when a protocol request to switch scenes is received, its state is updated to non-browsing state. If network latency causes state desynchronization, the client can also initiate a state calibration request to the server, using the most recently successfully synchronized state as the valid state for window rendering. This disclosure is not limited to this.

[0063] In step S230, based on the behavior state, the display format of the first window and / or the second window provided by the graphical user interface of the current terminal is determined. The first window displays the browsing content of the first virtual character in the browsing state, and the second window displays the browsing content or behavior state information of the second virtual character in the browsing state, based on the behavior state of the second virtual character. In this way, by dynamically adjusting the window display format according to the behavior state, players can still be aware of their friends' browsing activity in real time while performing other game actions, achieving cross-character information collaboration without interrupting the current operation. This effectively improves the efficiency of bidirectional parallel processing of browsing behavior and other game actions.

[0064] Optionally, the first window refers to the display area on the current terminal's graphical user interface used to present the content browsed by the first virtual character. When the first virtual character is in browsing mode, the first window is visible and renders the content currently being viewed by the first virtual character in real time (e.g., a list of stall items, a product details page, an item preview, etc.). When the first virtual character switches from browsing mode to non-browsing mode, the first window can be hidden or replaced with interface content related to the non-browsing mode behavior. The size, position, and layer hierarchy of the first window can be set according to interface layout requirements and user preferences. For example, the first window can display the virtual stall item display interface that the first virtual character is viewing in full screen; or the first window can occupy the left two-thirds of the graphical user interface and display the product catalog in a list view; or the first window can be minimized into a draggable floating panel that continuously displays thumbnail information of the currently viewed target.

[0065] Optionally, the second window refers to the display area associated with the second virtual character on the current terminal's graphical user interface. Its display format and content dynamically change according to the second virtual character's behavior. When the second virtual character is in browsing mode, the second window displays the browsing content (e.g., the stall items the second virtual character is currently viewing, product details, etc.), allowing the operator of the first virtual character to monitor the second virtual character's browsing progress in real time. When the second virtual character is not in browsing mode, the second window switches to displaying the second virtual character's behavior status information (e.g., combat indicators, movement indicators, team indicators, etc.), replacing the original browsing content display. The second window supports interactive operations such as moving, scaling, hiding, and expanding. For example, in browsing mode, the second window can display a list of stall items viewed by a friend in a split-screen format; in non-browsing mode, the second window can shrink to a status label, displaying a notification that a friend is currently engaged in a dungeon battle; and when multiple second virtual characters exist, each second virtual character corresponds to an independent second window, with multiple second windows presented simultaneously on the interface in a vertical or grid arrangement.

[0066] Optionally, the display form refers to the visual presentation of the first window and / or the second window on the current terminal's graphical user interface, including but not limited to combinations of parameters such as window visibility, size, position, transparency, layout, and content type. The terminal selects a matching display form from a variety of preset display form configurations based on the behavioral states of the first and second virtual characters, and renders the interface accordingly. For example, when both are in browsing mode, both the first and second windows adopt the first display form: displayed side-by-side in a split-screen manner; another example is when the first virtual character is in browsing mode while the second virtual character is not, the first window maintains the first display form, and the second window adopts a status icon display form: the second window shrinks to a status icon and is superimposed in the corner of the interface; yet another example is when the first virtual character is not in browsing mode while the second virtual character is in browsing mode, the first window is hidden, and the second window switches to a small window display form floating above the current interface; yet another example is when neither is in browsing mode, the first window is hidden, and the second window adopts a status icon display form. It should be understood that the above display styles are merely examples, and this disclosure does not limit them. The display styles can also be expanded according to the specific needs of the game scene.

[0067] In an optional implementation, the display format of the first window and / or second window provided by the current terminal's graphical user interface is determined based on the behavioral state. This includes: when both the first and second virtual characters are in a browsing state, the first and second windows are displayed in the graphical user interface in a first display format; in the browsing state, the second window is used to display the browsing content of the second virtual character. Thus, when both parties are browsing simultaneously, the two windows are presented on the same screen in the first display format, allowing players to browse their own content while viewing their friends' content, improving collaborative browsing efficiency and real-time interactive experience.

[0068] In one implementation, see Figure 6 When both the first and second virtual characters are in the virtual marketplace area and have enabled collaborative browsing, the graphical user interface of the current terminal is displayed in the first display form: the first window occupies the main area of ​​the interface and displays the details of the jewelry stall currently viewed by the first virtual character in real time, and the second window is displayed in a smaller area floating or in columns at the edge of the interface and simultaneously presents the equipment stall screen where the second virtual character is standing. When the second virtual character switches stalls, the content displayed in the second window is refreshed according to its perspective.

[0069] Optionally, both the first and second virtual characters being in a browsing state means that both participants in the collaborative browsing session are currently browsing products within a virtual transaction area. This state detection requires simultaneous monitoring of both parties' behavior state markers; the condition is met only if both parties' status markers are in a browsing state. In one embodiment, state detection is centrally performed by the server, which maintains the state information of each session participant and actively notifies relevant terminals when a state change is detected. In another embodiment, state detection is distributed, with each terminal reporting its own state, and other terminals determining whether both parties are in a browsing state based on the reported information. In yet another embodiment, state detection may include a brief state tolerance period. For example, if one party temporarily loses its state due to network latency, the system does not easily determine it as not in a browsing state but waits for a buffer period before making a final determination, avoiding frequent window switching due to momentary delays. After establishing a collaborative browsing session, when both parties are in a browsing state, they can exchange their current browsing content data, allowing each participant to see the other's real-time browsing perspective.

[0070] Optionally, the first display mode is used to simultaneously display the first window and the second window in dual browsing mode. The first window and the second window can be presented in different forms such as split screen, picture-in-picture, and floating pop-up, and this disclosure does not limit them. For example, the first display mode is a left-right split screen layout: the left side of the interface (occupying about 60% of the area) is the first window, displaying the details of the stall items that the first virtual character is browsing; the right side of the interface (occupying about 40% of the area) is the second window, displaying the item list of another stall that the friend is browsing, and there is a draggable separator between the two windows; another example is a picture-in-picture layout: the first window fills the entire interface, and the second window is superimposed on the lower right corner of the first window as a floating small window, with a size of about 1 / 4 of the first window; yet another example is a vertical stacked layout: the first window occupies the upper half of the interface, the second window occupies the lower half of the interface, there is a separator in the middle and the proportion can be adjusted by dragging. In actual display, the first window presents a complete panoramic view of the stall faced by the first virtual character, while the second window simultaneously loads the view of the stall currently occupied by the second virtual character. Its refresh rate is synchronized with the main view, ensuring real-time correspondence in browsing progress between the two. It should be noted that the above window proportions and layout are not intended to be exhaustively limited; they can be dynamically adapted based on the physical resolution of the terminal screen, screen orientation (portrait or landscape), or player preferences.

[0071] Optionally, in the first display mode, the first and second windows can be rendered using their respective independent UI hierarchy trees. During the compositing phase, the terminal combines the rendering results of the two windows into the same frame according to a predetermined layout scheme. The interaction events within the two windows are also isolated from each other, ensuring that clicks in the first window do not accidentally touch elements in the second window. For example, the terminal allocates an independent UI canvas object to each of the first and second windows, and touch events from both canvases are routed by the root container according to the window layout area based on the touch coordinates. Alternatively, the terminal can use two independent threads to render the first and second windows separately (when hardware supports it), and then merge the output to the screen using double buffering technology. Furthermore, when the user drags the separator between the two windows, the terminal recalculates the layout rectangle areas of both windows in real time and triggers a redraw.

[0072] In an optional implementation, the method further includes adjusting the display area ratio of the first window and the second window in response to a display layout adjustment operation for the windows. This provides window display layout adjustment functionality, allowing users to customize window area allocation according to current browsing needs and personal preferences. This adapts to changes in the level of attention given to the content browsed by the main user and collaborating partners in different scenarios, enhancing the personalization and adaptability of the graphical user interface and thus strengthening human-computer interaction control over the collaborative browsing window layout.

[0073] In one implementation, see Figure 7 When both the first and second virtual characters are browsing, the graphical user interface displays the first and second windows side-by-side. A draggable adjustment control is placed at the boundary between the first and second windows. Players can long-press the control and drag it left or right to change the horizontal proportion of the two windows on the screen in real time. For example, when the player needs to focus on the content browsed by the second virtual character, the display area of ​​the second window can be increased from 30% to 70%, while the first window shrinks accordingly, thus flexibly adapting to the player's instantaneous attention needs.

[0074] Optionally, the display layout adjustment operation is used to receive player-triggered operations on the window layout to adjust the display area ratio of the first and second windows. The interaction methods for this operation can include dragging the separator line or bar between windows, using control sliders, inputting ratio values, triggering preset ratio shortcut buttons, and pinching or extending gestures with two fingers. After receiving the layout adjustment operation, the terminal calculates the new window layout rectangle parameters in real time and triggers a re-layout and rendering of the graphical user interface. For example, if there is a vertical separator bar in the middle of the left and right split screen, the operator can drag the separator bar left or right to adjust the area ratio of the left and right windows in real time, with the content of the two windows scaling synchronously during the dragging process; another example is a ratio slider control provided at the bottom of the interface, which the operator can drag to continuously adjust the ratio; yet another example is three preset shortcut ratio buttons (3:7, 5:5, and 7:3) next to the interface separator bar, which can be clicked to switch between ratios with one click. The above display layout adjustment operation can be a sliding operation performed by the player on the touchscreen, an operation triggered by dragging specific adjustment controls in the interface with a mouse, or a layout adjustment command issued by the player through voice commands or gesture recognition.

[0075] Optionally, the window objects affected by the above-mentioned display layout adjustment operation are not limited to the proportional allocation between the first and second windows. When multiple second windows exist, players can simultaneously adjust the overall arrangement of multiple windows using the display layout adjustment operation. For example, when a player chooses to establish a collaborative browsing session with two second virtual characters simultaneously, the graphical user interface can display one first window and two second windows. In this case, the display layout adjustment operation can divide the screen horizontally into three equal parts, or fix the first window on the left side occupying 40% of the area, and arrange the two second windows vertically on the right side, jointly occupying 60% of the area. It should be understood that when the number of windows changes, the target area and adjustment logic of the display layout adjustment operation are generally different, but there are also cases where multiple windows are scaled uniformly. If a player only needs to adjust the area of ​​a single window, they can achieve local adjustment by clicking to select the window and then independently dragging its boundaries; this disclosure does not limit this approach.

[0076] Optionally, the display area ratio between the first and second windows can be dynamically changed based on adjustment operations to adapt to different browsing needs. The adjustment range of this display area ratio can be adaptively limited according to the size of the terminal screen. For example, on small-screen mobile terminals, the minimum display area of ​​any window should not be less than 20% of the total screen display area to ensure basic readability; while on large-screen devices or in landscape mode, this minimum limit can be relaxed or removed accordingly. Furthermore, the adjustment of the display area ratio can be continuous and stepless, or it can be adjusted in increments according to preset levels, such as providing multiple fixed ratio levels such as 33%-67% and 25%-75% for players to choose from. It should be noted that the above specific numerical descriptions of the display area ratio are only one example; in actual implementation, they can be determined based on terminal hardware parameters or player personalized settings.

[0077] Optionally, as the display area ratio dynamically changes, the browsing content displayed in the two windows can adaptively rearrange the layout or adjust the resolution to ensure that core information remains within the visible area. For example, when the display area ratio of the second window shrinks from 50% to 20%, the virtual item display interface in that window can automatically switch to a single-column compact list mode, hiding some non-critical descriptive text and only retaining the item icon and price; conversely, when the second window expands, it reverts to a two-column detail card mode and displays the complete item attributes. To avoid lag caused by repeated rendering of interface elements due to frequent ratio adjustments, the system can set a buffer delay mechanism, that is, the final ratio confirmation and content reload will be performed within a preset time after the player stops dragging.

[0078] In an optional implementation, the method further includes: when the behavior state of the first virtual character switches from browsing to non-browsing, switching the first window to a hidden state; and switching the second window from a first display mode to a second display mode, wherein the display area corresponding to the second display mode is smaller than the display area corresponding to the first display mode. Thus, when the first virtual character performs non-browsing behavior, by hiding the first window and reducing the display area of ​​the second window, players can simultaneously engage in gameplay and browse stalls, reducing interface obstruction and improving the efficiency of multitasking.

[0079] In one implementation, see Figure 6 , Figure 9When a player controlling the first virtual character enters a combat instance (not in browsing mode), the current terminal's graphical user interface immediately hides the first window, which originally occupied a large area of ​​the main interface. Simultaneously, the second window corresponding to the second virtual character in the instance, previously displayed alongside the first window (e.g., a large window occupying the left side of the screen), switches to a second display mode (e.g., a small window occupying the lower left corner of the screen). In this second display mode, the second window continuously displays thumbnails of the items currently being viewed by the player, allowing the player to observe their friend's activity while performing combat actions. Furthermore, the reduced display area of ​​the second window is significantly smaller than the previous first display mode, greatly reducing obstruction and interference with the main game screen.

[0080] Optionally, when the first virtual character is in a non-browsing state, the first window is switched to a hidden state to free up interface space for non-browsing activities.

[0081] Optionally, when the behavior state of the first virtual character changes from browsing to non-browsing, the first window in the graphical user interface, which was originally used to display the content browsed by the first virtual character, is hidden. In this hidden state, the first window no longer occupies a visible display area in the current interface, thus completely freeing up the original interface space for the scene or functional interface corresponding to the non-browsing behavior. Considering that when players participate in non-browsing behaviors such as dungeon battles, world exploration, or social interactions, their main field of view needs to be unobstructed to observe environmental changes or perform precise operations, switching the first window to a hidden state can, on the one hand, avoid visual interference from the browsing interface elements on the main battlefield, and on the other hand, reduce the graphics processing load of the terminal when rendering inactive windows. It should be noted that the above-mentioned hidden state can be either completely destroying the rendering layer of the first window, or adjusting the transparency of the first window to be completely invisible and pausing its internal dynamic refresh; this disclosure does not limit this.

[0082] Optionally, the second display form is the interface form presented by the second window after the first virtual character enters a non-browsing state. Its display area is significantly smaller than the first display form (i.e., the side-by-side large window form when both are in browsing state). In this second display form, although the area of ​​the second window is reduced, it still continuously displays the content browsed by the second virtual character in browsing state, such as displaying the virtual item icon, item name, and price information that the friend is viewing in thumbnail form. Considering that players only need to intermittently pay attention to their friend's stall activity when performing non-browsing behavior, compressing the second window into the second display form preserves information accessibility and greatly reduces the area obstructed by the main game interface. As a possible implementation, the second window in the second display form can be displayed floating in the lower right or lower left corner of the graphical user interface, with an area of ​​approximately 15% to 25% of the total screen area, or fixed at a preset compact ratio.

[0083] Optionally, in the second display mode, the item display method within the second window can be switched to a more compact layout different from the first display mode. For example, items originally displayed as a large icon grid in the first display mode can be switched to a horizontally scrolling list of small icons or vertically arranged minimalist text entries in the second display mode. The purpose of this layout switch is to sacrifice some visual detail to increase information density per unit area, allowing players to quickly scan multiple items while watching their friends browse the stalls. It should be noted that the above layout switch can be completed either by the terminal automatically adapting according to the instructions issued by the second display mode, or by adjusting the scaling ratio and arrangement rules of each element through the front-end rendering layer while keeping the data content unchanged. Regardless of the specific implementation method used, the second window should support real-time synchronization of the browsed content in the second display mode to ensure that the player of the first virtual character sees the latest browsing position of the second virtual character.

[0084] Optionally, the initial display position of the second window in the second display mode within the graphical user interface can be dynamically determined based on the type of current non-browsing behavior. For example, when the first virtual character enters a horizontal scrolling battle scene, the second window can be displayed by default in the upper right corner of the screen, where it is less likely to be obscured by gestures; when the first virtual character participates in a vertical bullet hell game, the second window can be displayed by default in the lower left corner of the screen to avoid the main enemy aircraft and bullet hell areas. Furthermore, to adapt to the screen sizes and resolutions of different terminals, the display area ratio corresponding to the second display mode can be finely adjusted while remaining smaller than that of the first display mode: on tablet devices, the second window can occupy approximately 20% of the screen area; on smartphones, it can occupy approximately 12% to 15% of the screen area. The purpose of this differentiated configuration is to ensure that the content of the second window is clearly discernible while maximizing the amount of interactive and visual space reserved for the non-browsing behavior of the first virtual character.

[0085] In an optional implementation, the method further includes: providing an expand control in the second window when the second window is switched to a second display mode; and restoring the second window to the first display mode in response to a trigger operation on the expand control. In this way, by setting the expand control in the second display mode, players can quickly restore the complete browsing view of the second window without interrupting their current operation, significantly improving the convenience and browsing efficiency of window mode switching.

[0086] See one example. Figure 9 When the second window is in the second display mode (small window mode), an expand control (such as a square icon with two-way arrows) will appear on the edge area of ​​the second window. When the player is performing other game actions, if they need to view the full content of the friend's window, they can click on the expand control. The second window will then smoothly expand from a small preview in the corner of the screen to the first display mode that occupies the main area of ​​the screen, and the friend's browsing content will be presented in full.

[0087] Optionally, the expand control is used to receive a trigger operation to restore the second window from the second display mode to the first display mode. Optionally, the expand control can be in various forms such as a virtual button, a floating action bar, or an edge hotspot on the second window. The visual presentation of the expand control can be a square icon with a double-headed arrow, a label with the words "Full Screen" or "Expand," or a semi-transparent white indicator bar on the edge of the second window. It should be noted that the position of the control can be set in the top title bar, the lower right corner area, or the border area on any side of the window; this disclosure is not intended to limit the specific form and position of the expand control. In one embodiment, when the second window is in the second display mode, the expand control automatically appears in the upper right corner of the window, and the player can trigger the window restoration process with a single click; in another embodiment, to avoid accidental touches, the expand control is only highlighted after the player has long-pressed or hovered over the second window for a preset time, thereby guiding the player to perform the expand operation.

[0088] Optionally, considering that players may want to fully browse their friends' browsing content while performing non-browsing gameplay, requiring them to re-enter browsing mode before restoring the second window to its first display state would significantly increase operational costs and negatively impact the gaming experience. Therefore, by providing an expand control locally within the second window, players can restore the friend's browsing window to its first display state with a single click without leaving the current game scene, thus balancing game operation and collaborative browsing needs. Furthermore, in addition to directly restoring the window state by clicking the expand control, the same window restoration logic can also be executed in response to double-clicking or swiping gestures on the second window; this disclosure is not limited to relying solely on a single virtual button.

[0089] In an optional implementation, the method further includes: providing a hidden control in the second window when the second window switches to a second display mode; switching the second window to a hidden state in response to a trigger operation on the hidden control; switching the hidden control to a displayed control; and restoring the second window to its second display mode in response to a trigger operation on the restored control. In this way, by setting a linkage switching mechanism between the hidden and restored controls in the small window state, players can flexibly control the visibility of the second window according to real-time game needs, avoiding the continuous obstruction of the main game interface by a fixed floating window. This significantly reduces the visual interference of the secondary window on the main game behavior while maintaining the connection for collaborative browsing.

[0090] In one implementation, see Figure 9 , Figure 10When the first virtual character enters a non-browsing state (e.g., entering a battle instance or story dialogue interface), the second window floats in the lower left corner of the current terminal's graphical user interface in a second display form. At this time, an arrow-shaped hidden control is displayed on the right edge of the second window. When the player taps this hidden control, the second window collapses and enters a hidden state; simultaneously, the area where the hidden control was previously displayed, or its adjacent edge, switches to display a restore control, which is exemplified as an arrow icon pointing in the direction of expansion (the opposite direction of hiding). When the player is temporarily idle during subsequent gameplay and wishes to review the browsing activity of the second virtual character, a single tap of the restore control will restore the second window from its hidden state to its default position in the graphical user interface in the second display form. Throughout this process, the collaborative browsing session remains connected without requiring a new invitation or session establishment.

[0091] Optionally, the hidden control is used to receive a hide trigger command for the second window, so as to control the second window to enter a hidden state in the second display mode. Optionally, considering that players need to minimize interface interference elements when participating in the main game, as a possible implementation, the above-mentioned hidden control can be configured as an operable element in the title bar area or edge touch area of ​​the second window in the small window mode. Its visual form can be, but is not limited to, a single horizontal thumbnail icon, an arrow pointing in the collapse direction, or a rectangular button with the word "collapse". After being triggered, the hidden control not only performs the action of hiding the second window, but also triggers the display logic of the restore control. It should be noted that the hidden control may not be an independent button, but a swipe gesture: the operator can trigger the hiding by swiping the small window to the edge of the interface, and the restore control will be displayed at the edge after swiping out.

[0092] Optionally, the restore control is used to receive a restore trigger command for the hidden second window, restoring the second window to its second display form. The restore control can be a static icon or button, or a bar-shaped notification. Its display position can be set by the system default to a non-touch hotspot area on the left or right side of the screen, or the player can customize its docking position by long-pressing and dragging. To facilitate the user's establishment of spatial memory associations, the display position of the restore control can be set at the edge of the interface corresponding to the position of the second window before it was hidden. Furthermore, when an unread event or target item triggers a notification, the restore control can attract the player's attention through visual changes such as changing its background color, adding a breathing light flashing effect, or popping up a miniature message bubble, ensuring that the player does not miss crucial collaborative browsing information even when the second window is completely hidden. It should be understood that the display level of the restore control can be set to always float on the top layer, or it can be set to temporarily avoid the view during game cutscenes; this disclosure does not limit this.

[0093] Optionally, the restore control and the hide control can be physically separated, or they can be presented at the same location through shape replacement. For example, the hide control can perform a shape transition animation the moment it is triggered, and then continue to be displayed at the original location with the visual style of the restore control after the animation ends, thereby reducing the cognitive burden on players searching for the restore entry. On the other hand, if the edge space of the graphical user interface is occupied by other system buttons, the restore control can also be configured to be stored inside the side swipe bar. When needed, players can bring up the swipe bar with an edge swipe gesture, and then click the restore option to recall the second window. In addition, the above-mentioned restore control can also be associated with the system's message notification center. When the second window is hidden, if a virtual item that meets the target filtering criteria is detected, the system can provide a restore entry in the form of a promotional card in the message notification center. Players can click the card to directly restore the second window and locate the corresponding item display position.

[0094] In an optional implementation, the method further includes: adjusting the position of the second window in the graphical user interface in response to a long-press and drag operation on the second window. This allows players to freely drag the second window to any blank area according to real-time interface requirements, preventing the floating window from obscuring key game screens or control areas, and ensuring interface visibility and operational accuracy during parallel browsing and gaming.

[0095] In one implementation, when the second window is in a floating small window state, if its current display position obscures the skill operation area below the graphical user interface, the player can press and hold the title bar area of ​​the second window for about 0.5 seconds, and the window will then enter a draggable state and move in real time with the finger; after the player drags the window to the blank area in the upper left corner of the screen and releases the finger, the second window will be fixed in the new position, thereby avoiding the originally obscured control area and ensuring that the player can still accurately trigger the underlying interface controls while browsing friends' booths in parallel.

[0096] Optionally, players can trigger a window repositioning mechanism by continuously pressing on the second window within the touch area of ​​the graphical user interface. The specific implementation of this long-press drag operation can be as follows: when the player's finger presses on the effective drag response area of ​​the second window and maintains the press for a preset duration (e.g., 300 milliseconds, 500 milliseconds, or 800 milliseconds), the second window switches from a static display state to a floating drag state that moves in real-time following the touch point. During the dragging process, the system continuously updates the rendering coordinates of the second window based on changes in the touch point coordinates until the player releases their finger, at which point the second window settles into its final display position. Furthermore, the draggable area of ​​the second window can be limited to the window's title bar area. The title bar only displays the character name and status markers and does not affect the content display area. Users can drag the window by long-pressing the title bar, but long-pressing the content area is recognized as an interaction with the content and will not trigger dragging. For small window designs without a title bar, the draggable area can be the entire window area. To avoid accidental operations, the system can set semantic recognition between content area interactions and drag operations. For example, a short press on the content area is considered a content click, and a long press on the content area is considered a drag operation. It should be noted that the above description of the drag response area and press duration is only one example, and this disclosure is not intended to limit the triggering form of long press drag operations.

[0097] Optionally, besides directly dragging the second window via a long-press and slide gesture on the touchscreen, the aforementioned position adjustment mechanism can also be executed in response to continuous triggering of the directional handle or joystick-style control by the player. For example, when the second window is in a small window state, four directional fine-tuning controls can be displayed at its edges. By long-pressing any directional control, the system shifts the anchor point coordinates of the second window sequentially along that direction at fixed time intervals or in fixed steps until the player releases the directional control and the displacement stops. Furthermore, to prevent the second window from being dragged out of the visible screen area and becoming irretrievable, the method can also determine the relative relationship between the window boundary and the screen boundary in real time during the window position update process. If it is detected that part of the second window's display area overflows the visible screen boundary, it is automatically bounced back to a preset safe distance inside the screen edge. In other words, the long-press and drag operation can not only be a direct gesture drag but can also evolve into other continuous position adjustment commands; this disclosure does not limit this.

[0098] In an optional implementation, the method further includes: receiving target filtering conditions; after the collaborative browsing session is established, monitoring whether there are virtual items that meet the target filtering conditions in the browsing content of the second virtual character in the browsing state; when a virtual item that meets the target filtering conditions is detected, the second window is also used to display a corresponding prompt. In this way, by introducing an automatic filtering and prompting mechanism for target items during collaborative browsing, participants in collaborative browsing can automatically receive notifications of their partner discovering target items while focusing on their own game activities. This avoids the inefficient mode of manually continuously monitoring the other party's browsing content, significantly improving the efficiency of item location and transaction in collaborative browsing scenarios.

[0099] In one implementation, after establishing a collaborative browsing session, the first virtual character can submit a specific virtual item they want to find and its corresponding acceptable price range as target filtering conditions. The system then continuously monitors the browsing content of the second virtual character during the collaborative browsing session. When a virtual item that meets both the above requirements and price conditions appears in a stall browsed by the second virtual character, the current terminal immediately generates a prompt in the second window with a highlighted border and dynamic flashing effect. For example, if the first virtual character sets its target filtering condition as wanting to purchase a weapon called "Swift Blade" for 500 to 800 virtual coins, and a "Swift Blade" priced at 600 virtual coins appears in a stall browsed by a friend, the weapon icon in the second window will immediately flash continuously with a golden light effect, allowing the first virtual character to directly locate and click to purchase without having to search page by page.

[0100] Optionally, target filtering criteria are a set of query conditions set by the user before or after the establishment of a collaborative browsing session to specify the characteristics of virtual items they are interested in. Target filtering criteria can include filtering parameters across multiple dimensions: item type (e.g., weapon, armor, accessory categories); item quality (e.g., common, rare, epic, legendary quality levels); item attribute (e.g., attack power, defense power, critical hit rate ranges); price (e.g., minimum price, maximum price, price range); item level (e.g., applicable character level range); and item source (e.g., drops from specific dungeons, output from specific events). In one embodiment, the target filtering criteria setting interface is presented in form, where users input filtering parameters using dropdown menus, sliders, checkboxes, and other controls. In another embodiment, target filtering criteria can be input via natural language, with the system parsing the user's input text description into structured query conditions. In yet another embodiment, target filtering criteria support saving and switching between multiple sets of conditions, allowing users to save several common filtering schemes and quickly switch between them in different scenarios.

[0101] Optionally, receiving target filtering conditions refers to the process by which the system obtains and persistently stores the filtering parameters input by the user. The channels for receiving these conditions may include: receiving filtering conditions through a settings panel during the preparation phase before the collaborative browsing session is established; adding or modifying filtering conditions in real time through the session management interface after the session is established; or quickly selecting from a preset filtering scheme library. In one embodiment, the system associates and saves the received target filtering conditions with the collaborative browsing session object. When multiple second virtual roles exist in the session, the filtering conditions apply to the browsing content of all second virtual roles. In another embodiment, filtering conditions can be set for specific second virtual roles, i.e., different filtering targets can be set for different partners in the collaborative browsing. In yet another embodiment, the system also supports setting the effective time range of filtering conditions, such as being effective only within the first 30 minutes after the session is established, and automatically expiring after that. In yet another embodiment, receiving filtering conditions may also include condition validity verification; the system checks whether there are contradictions in the conditions input by the user, such as providing a prompt when the upper price limit is lower than the lower price limit.

[0102] Optionally, monitoring whether virtual items matching the target filtering criteria exist in the browsing content of the second virtual character can be performed locally on the terminal or on the server, with the matching results pushed to the terminal. In local comparison mode, after receiving the browsing content data of the second virtual character (e.g., the list of items currently being browsed at a stall), the terminal extracts the attribute fields of each item and performs matching calculations against the target filtering criteria. In server-side comparison mode, the terminal uploads the target filtering criteria to the server. Before pushing the browsing content data of the second virtual character to the terminal, the server performs condition filtering and sends the matching flag along with the data. For example, after receiving the browsing content update data packet from the second window (containing the ID, category, and price fields of 10 products), the terminal iterates through these 10 products and compares them one by one to see if they meet the category and price conditions set by the operator. If a match is found, the product is marked on the interface. Another example is that the terminal encodes the filtering conditions into a structured filter expression and sends it to the server. The server automatically includes a boolean flag indicating a match and a list of indexes of matched products each time browsing data is pushed. Yet another example is that the terminal adopts an incremental monitoring strategy: it only compares items in the browsing content data that have changed, and skips repeating comparisons of items that have already passed the comparison but have not changed.

[0103] Optionally, the prompt indicator is used in the second window to identify virtual items that meet the target filtering criteria to the first virtual character. Its visual presentation dynamically adjusts with the window's shape to ensure the first virtual character can promptly perceive the appearance of the target virtual item in different usage scenarios. In the second display mode or the first display mode where the second window is displayed in a larger area, the prompt indicator can directly apply a highlighted outline, flowing border, or pulsed scaling light effect around the identifier of the virtual item that meets the target filtering criteria, making the item significantly different from surrounding ordinary goods in the item list. For example, when a target weapon with a price within a preset range appears in a stall browsed by the second virtual character, the border of the weapon icon in the second window immediately switches to gold and is accompanied by a periodic breathing light animation, allowing the player to quickly lock onto the target in a complex interface without having to read text line by line. When the second window is switched to a hidden or collapsed state, since the detailed item list is no longer visible, the prompt indicator can be transformed into a pop-up bubble message, floating card, or red dot marker on the edge of the graphical user interface or in a floating layer. The bubble message can display a thumbnail of the target virtual item, price information, and quick operation entry. In other words, the aforementioned prompts are not fixed to a single visual style, but automatically switch between different presentation formats in response to changes in the second window's shape, balancing timely information delivery with efficient use of interface space. Furthermore, in addition to visual prompts, a multi-dimensional prompt system can be constructed by incorporating sound and vibration feedback, and the triggering of these sounds or vibrations can be linked to the value level of the target virtual item. Moreover, the visual style of the prompts can be layered based on the degree of matching of the target selection criteria: if both the item identifier and price range are met, the strongest prompt is activated; if only the item identifier is met but the price slightly exceeds the range, a medium-intensity prompt can be activated as a reference. This multi-dimensional prompt design allows players to flexibly perceive information according to their own situation, preventing them from missing trading opportunities due to ignoring a single prompt format.

[0104] Optionally, in addition to serving as a visual reminder, the prompt can be deeply integrated with the transaction process to shorten the behavioral path from discovering the target to completing the purchase. Considering that players usually have the intention to view or purchase immediately after seeing the prompt, as a possible implementation, the prompt itself can be configured as an interactive control. The first virtual character can directly jump to the details page of the target virtual item by clicking the prompt or its associated area, and then execute the transaction. In one implementation, when the second window displays the prompt with special effects in an expanded state, the first virtual character can directly click the highlighted item icon to enter the purchase confirmation interface and complete the payment; when the prompt exists in a bubble form in a collapsed or hidden state, a one-click purchase control or a purchase queue control can be embedded in the bubble. After the player clicks, the instant transaction process can be triggered or the item can be temporarily stored in the queue for later settlement. Furthermore, if multiple virtual items that meet the target filtering criteria appear simultaneously in the stalls currently being viewed by the second virtual character, the prompts can be sorted and displayed according to priority rules such as price from low to high or rarity from high to low, prioritizing the display of items with higher cost-effectiveness or better meeting the player's core needs in more prominent positions. It should be understood that the interaction depth and display priority rules of the prompts can be flexibly set according to the economic system design requirements of different game types, and this disclosure does not impose any limitations on this.

[0105] In an optional implementation, the target filtering criteria include the target virtual item identifier and its corresponding price range. By refining the target filtering criteria to a dual constraint of item identifier and price range, the accuracy of the filtering can be improved, effectively reducing invalid suggestions and enabling players to more efficiently find suitable trading targets.

[0106] For example, see Figure 8 , Figure 12 After entering a collaborative browsing session, players can select items they are interested in from a list of item icons provided in the target filter settings interface, and set the corresponding expected price range. This interface also displays the items currently being viewed and the expected prices set by friends participating in the collaboration. When a friend-controlled second virtual character browses the item in a stall, as long as its price falls within the aforementioned range, the system will display a prominent visual effect with a flashing border in the second window. Players can then directly click on the item icon to view details and initiate the transaction, thus avoiding being distracted by similar items with mismatched prices.

[0107] Optionally, the target virtual item identifier is used to indicate the virtual items to be filtered, so that the system can match and monitor the browsed content during collaborative browsing. The identifier can take various forms: item name is the most common form, where the user directly enters the item's name string as the matching basis; item code is a unique numeric or alphanumeric code assigned to each item by the system, which the user can directly enter for precise matching if the code is known. In one embodiment, the target virtual item identifier also supports fuzzy matching, where the user enters keywords instead of the full name, such as entering "Shadow" to match all items with the "Shadow" affix in their names, such as Shadow Blade, Shadow Ring, and Shadow Staff. In another embodiment, the target virtual item identifier can be entered via item icon selection. The system displays an item icon library, and the user searches for and selects the target item, reducing the tediousness of text input. Considering the different needs of players at different stages of the game, as a possible implementation, multiple target virtual item identifiers can be set simultaneously, for example, allowing players to select multiple different equipment or materials at once, and the system triggers a prompt when any target item is detected.

[0108] Optionally, the price range is used to limit the trading price of the target virtual item within a certain range, which, together with the target virtual item identifier, constitutes the basis for judging the target filtering conditions. In one implementation, the above-mentioned price range can be not only a closed range, such as 1000 to 2000 game coins, but also a semi-open range or a single boundary limit, such as not higher than 1500 game coins or not lower than 500 game coins. Considering the price fluctuation characteristics of the virtual market, as a possible implementation, the system can also provide players with a default recommended price range value based on the recent average transaction price or average listing price of the target virtual item, which players can then fine-tune. It should be noted that the above-mentioned price range setting method is only one example, and this disclosure is not intended to limit the method of determining the price range. Under the economic system of different games, the currency unit used for the price range can be game coins, points, tokens, or other virtual transaction mediums. By providing a flexible range setting method and intelligent recommendation mechanism for the price range, the manual input burden on players can be reduced while ensuring the filtering accuracy, making the prompts for the target item more consistent with the actual market conditions.

[0109] Optionally, the input method for the target virtual item identifier and price range can be completed by the player at any time before or after establishing a collaborative browsing session through the graphical interface. The operator can select the target item from the list of icons corresponding to virtual items displayed in the interface and add it to the monitoring list. The system will automatically extract the unique identifier of the item based on the corresponding icon. The price range can be set by dragging the dual-ended slider provided in the interface, or by directly entering a value in the data input box. The above input methods for the target virtual item identifier and price range are only examples, and this disclosure does not limit them.

[0110] In an optional implementation, the browsing content includes virtual items. When a virtual item that meets the target filtering criteria is detected, the second window is further used to display a corresponding prompt, including: in response to the detection that the browsing content of the second virtual character contains a target virtual item corresponding to the target virtual item identifier, and the price of the target virtual item is within the corresponding price range, the identifier corresponding to the target virtual item is displayed in the second window with a prominent visual effect. In this way, by applying differentiated visual rendering to the target items that meet the filtering criteria in the second window, players can promptly capture trading opportunities during parallel gameplay, thereby shortening the decision-making process and improving collaborative browsing efficiency.

[0111] In one implementation, a second virtual character controlled by a second terminal is browsing a stall selling virtual items. When the system detects a weapon named "Thunder Blade" in the stall, priced at 1200 virtual coins and within the player's preset price range of 800 to 1500, the weapon's thumbnail icon immediately displays a continuously pulsating golden-yellow glowing border in the second window displayed on the player's corresponding terminal. This differentiated visual rendering prompts the player that the target item has appeared. The player can quickly focus their attention on this displayed area, knowing that a product matching the filter criteria has been found in the collaborative browsing session without manually browsing each item. Furthermore, if the second window has switched to a smaller display mode, the glowing border effect can be simplified to a static outline superimposed on a bright background, ensuring that the icon corresponding to the target virtual item remains clearly visible in the reduced window size.

[0112] Optionally, the aforementioned prominent visual effect is used to highlight the target virtual item in the second window to guide the player's visual focus. This effect can be implemented through either dynamic rendering or static enhancement. Specifically, when the system detects that the second virtual character's browsing content includes the specific item indicated by the target virtual item icon, and the item's price is within a preset price range, the prominent visual effect can be applied to the corresponding item location in the second window. For example, this effect can be a continuous highlight outline around the edge of the item's thumbnail icon, or it can be a superimposed effect of dancing starburst particles on the icon's surface. Considering that the first virtual character often engages in other game activities during collaborative browsing, resulting in a scattered visual attention, the aforementioned differentiated visual methods can quickly guide the player's gaze to the target object, even if the second window is displayed in a small floating area, thus enabling timely identification of the target virtual item.

[0113] Optionally, to further reduce the probability of players missing target items, the aforementioned prominent visual effects can be combined with short sound cues or device vibration feedback to form a complete expression of the prompt in a multimodal manner. It should be noted that the above description of the implementation of visual effects is only one example, and this disclosure is not intended to limit its specific form. In actual implementation, adjustments can be made flexibly based on the overall art style of the graphical user interface, the current terminal's graphics rendering performance load, and the user's own preferences. For example, players can be allowed to disable high-energy-consuming dynamic effects in the game settings options, retaining only static border color changes, to accommodate the smooth operation requirements of different terminals.

[0114] In an optional implementation, the method further includes: when a virtual item that meets the target filtering criteria is detected, if the second window is hidden, displaying a prompt message associated with the target virtual item in the graphical user interface. This way, even when the second window is hidden, players can promptly learn of the target virtual item's appearance without repeatedly opening the window, effectively balancing the parallel efficiency of main game activities and collaborative browsing.

[0115] In one implementation, see Figure 11The first virtual character is currently in a non-browsing state (e.g., participating in an competitive battle), and has hidden the second window in the collaborative browsing team, leaving only the restore control floating at the edge of the interface. At this time, the second virtual character, in the browsing state, discovers a virtual item that meets the target filtering criteria (e.g., a virtual item priced at 8888 game coins). After the system monitors the virtual item that meets the criteria in real time, it determines that the second window is currently hidden, and then pops up a notification message in the graphical user interface of the first virtual character's competitive battle in the form of a lightweight bubble. The notification message is displayed floating in the lower left corner of the interface, and the content includes at least the icon and price information of the virtual item, to remind the first virtual character to pay attention to the appearance of the target item.

[0116] Optionally, a notification message refers to an information carrier actively displayed in the graphical user interface when the second window is hidden, used to inform the operator that a virtual item meeting the target filtering criteria has appeared. Its form and position can be adjusted. The notification message can take the form of a banner notification, floating bubble, pop-up dialog box, status bar message, etc. The content of the notification message can include key information such as the name, price, brief attributes, and name of the friend from whom the item was found. Considering that after switching the second window to a hidden state, the player's main attention is usually focused on the currently ongoing non-browsing activity (such as dungeon battles or competitive combat), to avoid excessive obstruction or interference with the player's main field of vision, as a possible implementation, the notification message can be displayed in a relatively peripheral or low-interference area of ​​the graphical user interface, such as below the status bar at the top of the interface, on the opposite edge of the main control joystick, or near the chat information bar. It should be noted that the timing of this prompt message is directly related to the hidden state of the second window. In other words, the prompt message will only be triggered when the second window is currently hidden and the system detects virtual items that meet the target filtering criteria. If the second window is already in an expanded or normally displayed state, the system can directly display the prompt within the second window to highlight the visual effect, without popping up the prompt message again, thereby reducing the redundancy of interface elements.

[0117] Optionally, the display duration of the notification message can be set. If no trigger action is received for the notification message within the preset time, the display can be canceled to avoid prolonged obstruction or interference with the player's main interface. Considering that players may not have time for precise clicks during combat, the duration of the notification message on the interface can be intelligently adjusted according to the player's current behavior. For example, when the first virtual character is detected to be in a combat phase without browsing, the duration of the notification message can be extended to 1.5 to 2 times that of the normal standby state, to reduce the probability of players missing trading opportunities due to insufficient time to view the message. If multiple virtual items that meet the target selection criteria are detected at the same time, the notification message can also be displayed by stacking cards or rotating, rather than simply overwriting the earlier notification with the later one, thus ensuring that the appearance of each target virtual item can be effectively perceived by the player.

[0118] In an optional implementation, the method further includes: in response to a triggering operation on a prompt message, displaying a details page for the target virtual item, the details page being used to perform transaction processing on the target virtual item. Thus, during collaborative browsing, even if the second window is hidden, players can directly access the details page of the target virtual item and complete the transaction through the prompt message, without interrupting their current game activity to open the main browsing interface, thereby improving shopping efficiency and the multitasking experience.

[0119] In one implementation, when the second window is hidden and the system detects a virtual item matching the target filter criteria in a friend's currently viewed stall, a notification message with a thumbnail and name of the item will pop up on the graphical user interface. Upon receiving this notification while in a dungeon battle, the player immediately clicks the notification, and the system then displays a semi-transparent details page overlaid on the current screen. This details page shows the virtual item's attributes, price, and a purchase button. After confirming the price meets expectations, the player can directly click the purchase button to complete the transaction. Throughout the process, the dungeon battle does not need to be paused, and the collaborative chat between friends browsing stalls continues.

[0120] Optionally, a details page refers to a complete information display page provided by the terminal for a specific virtual item. This page includes comprehensive attribute data of the virtual item (such as basic attributes, additional attributes, level requirements, durability, and trading price) and accessible operations for that item (such as purchasing, bidding, auctioning, adding to shopping list, and sharing with friends). The content displayed on the details page can be generated based on item data extracted from the browsing content of a second virtual character, or it can be generated based on complete item data returned by the server. The organization and layout of the details page can be flexibly set according to game requirements, and this disclosure does not impose any limitations on this.

[0121] Optionally, transaction processing refers to the complete business process executed on the details page to transfer ownership of virtual items from the seller to the buyer, involving currency deduction and item transfer. After a player initiates a purchase request through the transaction controls on the details page, the backend server verifies the virtual currency balance in the player's account, and upon successful verification, deducts the amount and simultaneously distributes the corresponding target virtual item to the player's account.

[0122] This embodiment of the disclosure designs the prompt message as an interactive entry point, allowing users to directly access the product details page with one click after seeing the target item prompt, and complete the transaction directly on the details page of the current terminal, without having to manually search or browse the stall again to find the item. This greatly shortens the transaction path from discovery to purchase, reduces the rendering waiting time and operation delay caused by interface jumps and manual positioning, and improves the transaction conversion efficiency of target items in collaborative browsing.

[0123] In an optional implementation, the method further includes: a prompt message including an add control; and, in response to a triggering operation on the add control, adding the target virtual item to the purchase queue. Thus, by including an add control in the prompt message, players can add the target virtual item to the purchase queue with a single click for later processing, effectively preventing frequent interruptions to the game process due to real-time trading operations.

[0124] For example, see Figure 11 The notification message may include an add control that indicates storage. After the player clicks the add control, the corresponding target virtual item will be stored in the purchase queue for the player to view and process later.

[0125] Optionally, the add control refers to an interactive element provided in the prompt message, used to add the target virtual item associated with the prompt message to the purchase queue. The visual form of the add control can be a plus button, a favorites icon button, a "process later" button, etc., and its specific presentation can be adapted to the overall interface style of the prompt message. Considering that when players are not browsing (e.g., performing dungeon battles or real-time arena operations), their attention is focused on the current core gameplay and it is difficult to immediately allocate attention to complex transaction confirmation processes. As a possible implementation, by providing an add control in the prompt message, the system allows players to quickly add the target virtual item to the purchase queue with a single click or tap, without immediately jumping to the product details page or performing cumbersome payment operations. This add control can be displayed directly at the bottom area of ​​the prompt message, or it can float on the right or left edge of the prompt message, and its display parameters can be dynamically switched according to the remaining space in the current graphical user interface.

[0126] Optionally, the "Wanted to Buy Queue" refers to a list of pending items maintained by the terminal, used to temporarily store virtual items that the operator is interested in but not yet ready to purchase. The Wanted to Buy Queue can be displayed in a separate panel interface, allowing the operator to view the added item list, sort and filter items, remove items no longer in interest, and perform purchases individually or in batches. For example, the Wanted to Buy Queue panel can be pulled out from the right side of the screen as a side drawer, displaying all added items in a vertical list format, with "Buy" and "Remove" buttons on the right side of each item. Alternatively, the Wanted to Buy Queue can be sorted by price in ascending order or by addition time, allowing the operator to purchase the lowest-priced item in the queue with a single click. Furthermore, item entry information in the Wanted to Buy Queue is subject to expiration and cleanup: when an item has been purchased by a friend or removed from the shelves, the corresponding entry is automatically marked as expired and moved to the expired section at the bottom of the queue. In addition to recording the item identifier of the target virtual item, the Wanted to Buy Queue can also record the price at the time the item was added, the stall identifier, and the timestamp information, thus providing sufficient data for subsequent transaction decisions.

[0127] Optionally, the terminal can send a notification to the operator when the price of an item in the purchase queue changes (price decreases or increases), or proactively display a summary notification of items in the queue when the operator leaves combat or is not in a browsing state. For example, if the system detects that the price of an item in the queue has decreased by 15%, a price reduction notification will pop up on the interface; or, for example, when the operator switches from combat to standby, the terminal will proactively display a summary overlay of the purchase queue, showing an overview of all items in the queue.

[0128] In an optional implementation, the method further includes: displaying details of the target content in response to a selection operation on the browsed content displayed in the second window; and / or performing transaction processing on the target content. This allows players to directly select items browsed by friends in the collaborative browsing interface and quickly view details or complete transactions, avoiding the tedious operation of repeatedly switching interfaces and significantly improving the efficiency of virtual item transactions and the convenience of collaborative browsing.

[0129] For example, a first player is browsing their own stall while simultaneously viewing items from another stall being browsed by a second player through a second window. The first player sees a helmet of interest in the second window and taps its icon. Upon detecting the selection, the second window displays a semi-transparent details overlay on the current screen, showing the helmet's complete attributes and current price, and providing transaction controls. The first virtual character can then trigger these controls to directly execute a transaction on the helmet.

[0130] Optionally, the above selection operation aims to receive input commands from the player regarding the content browsed in the second window, in order to determine the target object to be processed. The interaction form of the selection operation can be various gestures such as clicking, double-clicking, long-pressing, and swiping, or it can be voice command selection or gesture selection, etc. This disclosure does not limit its specific interaction form. It should be noted that the above-mentioned second window can receive the selection operation in different display forms, whether it is the large window display state in the first display form or the small window floating state in the second display form. In one embodiment, each virtual item displayed in the second window is set as a selectable object, and the surface of the item is covered with an invisible interactive layer. The user clicks on any part of this area to trigger the selection operation of the item. The hot spot response area of ​​the interactive layer can be adaptively scaled according to the current actual display ratio of the second window to ensure that the player can accurately trigger the selection in different window sizes. In another embodiment, the second window can also support batch selection. After clicking the first item, the user presses the multi-select button and then clicks subsequent items to select multiple items at the same time. The system provides batch detail display or batch transaction processing capabilities for the batch-selected items.

[0131] Optionally, the detailed information of the target content refers to the multi-dimensional attribute data related to the virtual item that the system loads and displays in the graphical user interface after the selected operation is executed. The content varies depending on the type of target content: if the target content is a virtual item, the detailed information includes an item attribute panel, price information, transaction records, source information, etc.; if the target content is a trading stall, the detailed information includes the stall name, stall owner information, overview of listed items, etc. Furthermore, the detailed information may also include dynamic attributes, such as the historical transaction price fluctuation curve of the item in the trading market, the current server's inventory statistics of similar items, or the personalized notes and tags of the second virtual character for the item. The detailed information can be displayed in a pop-up window, a full-screen modal page, a side panel, etc., and this disclosure does not limit this.

[0132] Optionally, the transaction processing for the target content includes, but is not limited to: sending a purchase request to the server and completing currency deduction and item transfer, sending a bidding request to the server, sending a negotiation message to the seller, and adding the item to the purchase queue. The transaction processing can be completed directly in the details display interface, or it can be triggered directly without displaying details (e.g., long-pressing the item and selecting one-click purchase from the shortcut menu).

[0133] Optionally, if the target content is currently in a non-tradable state (e.g., it has been purchased by other virtual characters, the item has been removed from the shelves, the price has changed, etc.), the terminal verifies the current status with the server when the operator selects the target content. If it is no longer available, the corresponding status prompt information is displayed (e.g., the item has been sold, the price has been updated to xxx, etc.), and the browsing content in the second window can be automatically refreshed to display the latest status (e.g., the position of the item in the second window is displayed with a gray overlay).

[0134] This embodiment allows users to take action on products of interest directly in the browsing view of their collaborating partner without having to switch to a dedicated product transaction interface or leave the collaborative browsing interface. This enables direct cross-window interaction and quick transactions in collaborative browsing, thereby reducing the data processing overhead caused by function switching and context recovery.

[0135] In an optional implementation, the method further includes: when the behavior state of the second virtual character switches from browsing state to non-browsing state, switching the second window from the first display mode to the status indicator display mode; in the non-browsing state, the second window is used to display the behavior status information corresponding to the second virtual character. Thus, when the second virtual character interrupts browsing and enters other behavior, the terminal automatically switches the displayed content of the second window from browsing content to behavior status information. The operator does not need to query the current whereabouts of friends through other channels (such as friend lists or chat channels), reducing the rendering switching overhead caused by cross-interface query operations, and also avoiding the second window continuing to occupy rendering resources to display meaningless, expired browsing content when the other party is not browsing.

[0136] See one example. Figure 13 When a second virtual character is browsing an equipment list at a stall, if that character responds to a team invitation and enters a battle scene, switching to a non-browsing state, the current terminal detects this state change and switches the second window in the graphical user interface from its first display mode to a status indicator display mode. In this mode, the second window no longer displays virtual items but instead shows the second virtual character's real-time behavioral status information as status labels, such as the overlay text "Xiaoxiao Dragon Prince in battle." Thus, the first virtual character can intuitively know that their friend is temporarily unable to continue browsing without interrupting their own browsing or game progress, effectively reducing the interactive confusion caused by the sudden disappearance of window content.

[0137] Optionally, the status indicator display mode is a simplified display mode for the second window when the second virtual character is not browsing. The design goal of this mode is to convey the current status information of the collaborating partner with minimal interface footprint. The display area of ​​the second window in status indicator mode can be smaller than that in the first display mode to save interface space. Its displayed content changes from browsing content (such as product lists, item details) to behavioral status information (such as behavioral status icons, behavioral status text descriptions, status duration, etc.). The visual presentation of the status indicator display mode can take various forms, such as text labels, graphic logos, dynamic avatar overlays, or minimalist information cards. Considering that if players suddenly lose the content of the other player's window during collaborative browsing, it may lead to misunderstandings of session interruption or system failure, the introduction of the status indicator display mode maintains the sense of window persistence even when the second virtual character temporarily leaves browsing. This clearly informs the first virtual character that the other party is still online and in a collaborative session, and also helps maintain the continuity of two-way interaction.

[0138] Optionally, in the status indicator display mode, the behavioral status information displayed in the second window may include, but is not limited to, combat status, dungeon loading status, team waiting status, shop interface browsing status, or system settings interface status. The specific information type can be automatically identified and matched with corresponding status description text by the client based on the game module the second virtual character is currently in. The update frequency of the above status information can adopt a real-time push mechanism or be polled and refreshed according to a preset period, such as checking the behavioral status of the second virtual character every 2 seconds to ensure the timeliness of the status indicator. Furthermore, if the system detects that the second virtual character is in a state of network latency or brief unresponsiveness, the status indicator display mode can be extended to display a transitional indication of "Status Synchronizing" or "Network Recovering," thereby providing a fallback display for various abnormal boundary situations and effectively avoiding misjudgments by players due to missing information.

[0139] This embodiment uses a status indicator display instead of directly closing or hiding the second window. This not only avoids the unpleasant experience of the collaborative browsing session being interrupted due to friends temporarily engaging in other game activities, but also allows the first virtual character to keep track of teammates' dynamics while continuing their own browsing or combat activities, thereby providing information for subsequent collaborative decision-making.

[0140] In an optional implementation, the method further includes: restoring the second window to the first display mode when the second virtual character's behavior state changes from a non-browsing state to a browsing state. This way, when a friend finishes other game activities and returns to browsing the marketplace, the interface automatically reverts to the collaborative browsing dual-window view, ensuring the continuity and integrity of the collaborative experience and avoiding tedious manual operations for the player.

[0141] In practical applications, when the second virtual character is in a non-browsing state due to participating in virtual battles, its corresponding second window displays the battle prompts of the virtual character in the form of a status indicator; when the second virtual character ends the battle and returns to the virtual trading area to browse, the system monitors in real time that the behavior status has changed from non-browsing to browsing, and then triggers the second window to automatically change from the status indicator display form to the first display form, so that the graphical user interface of the current terminal re-presents the real-time stall browsing content of the second virtual character, realizing the seamless connection of the collaborative browsing session.

[0142] Optionally, the second window's restoration to the first display mode is triggered by the second virtual character returning to the browsing state, aiming to automatically rebuild the collaborative browsing view and maintain session continuity. Optionally, when the second virtual character restores from a non-browsing state to a browsing state, the current terminal receives real-time state synchronization data from the second terminal. This state synchronization data at least includes the current behavior identifier of the second virtual character. The window management module in the graphical user interface parses this behavior identifier and determines that it meets the definition conditions of the browsing state. Then, it immediately sends a restoration command to the view rendering layer, switching the second window from the state identifier display mode to the first display mode. In this first display mode, the second window reloads and presents the stall interface currently occupied by the second virtual character and the virtual item information stream it is browsing in real time. It should be noted that, to avoid frequent window switching due to network latency or state jitter, a preset stable duration mechanism can also be introduced into the above state determination logic. For example, the form restoration is triggered only after the browsing state has been continuously monitored for a specified duration, thereby improving the stability of the interface display and the continuity of the visual experience. At the same time, the specific value of this stable duration can be flexibly set according to the network environment or application scenario, and this disclosure does not limit it.

[0143] Optionally, considering the varying needs of player collaboration in different application scenarios, the above recovery logic can be designed as either fully automatic and seamless switching, or as a semi-automatic mode. That is, when the second virtual character is detected to have resumed browsing, a confirmation pop-up appears in the graphical user interface, waiting for the first virtual character to click confirmation before the second window's appearance is restored. Furthermore, if the first virtual character is currently in a non-browsing state, such as during a dungeon battle, the second window can still be presented as a small window in Form Two, rather than directly switching to the large window of Form One displayed side-by-side. This allows the visibility of the friend's browsing content to be restored in a non-disruptive manner while the first virtual character continues other game activities, addressing the anti-interference needs in various scenarios.

[0144] According to one embodiment of the present disclosure, the information processing apparatus may include: A session establishment module is used to establish a collaborative browsing session between a first virtual character and at least one second virtual character. The first virtual character is controlled by the current terminal, and the second virtual character includes a virtual character controlled by the second terminal and / or an uncontrolled virtual character. The behavior monitoring module is used to monitor the behavior status of the first virtual character and / or the second virtual character, including at least the browsing status and the non-browsing status. The display control module is used to determine the display format of the first window and / or the second window provided by the graphical user interface of the current terminal according to the behavior state. The first window is used to display the browsing content of the first virtual character in the browsing state, and the second window is used to display the browsing content or behavior state information of the second virtual character in the browsing state according to the behavior state of the second virtual character.

[0145] In this way, by monitoring the behavior status and adaptively adjusting the window display form, the interface switching overhead under multi-task parallelism is reduced, which helps to reduce redundant operation instructions, reduce terminal rendering and processing load, and improve interface resource utilization and parallel operation efficiency.

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

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

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

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

[0150] 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 15 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.

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

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

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

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

[0155] 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. An information processing method, characterized in that, The method includes: Establish a collaborative browsing session between a first virtual character and at least one second virtual character, wherein the first virtual character is controlled by the current terminal, and the second virtual character includes virtual characters controlled by the second terminal and / or uncontrolled virtual characters; Monitor the behavioral state of the first virtual character and / or the second virtual character, the behavioral state including at least browsing state and non-browsing state; Based on the behavioral state, the display format of the first window and / or the second window provided by the graphical user interface of the current terminal is determined, wherein the first window is used to display the browsing content of the first virtual character in the browsing state, and the second window is used to display the browsing content or behavioral state information of the second virtual character in the browsing state according to the behavioral state of the second virtual character.

2. The method according to claim 1, characterized in that, The establishment of a collaborative browsing session between a first virtual character and at least one second virtual character includes: In response to detecting at least one second virtual character that meets preset collaboration conditions, a collaborative browsing session is established between the first virtual character and the at least one second virtual character.

3. The method according to claim 2, characterized in that, The preset coordination conditions include: Both the first virtual character and the second virtual character are located within a preset virtual trading area; and / or, The first virtual character and the second virtual character have a social relationship.

4. The method according to claim 2, characterized in that, The establishment of a collaborative browsing session between the first virtual character and the second virtual character includes: The collaborative browsing entry is displayed on the graphical user interface of the current terminal; In response to the triggering operation of the collaborative browsing entry, a collaborative browsing request is sent to the second terminal; In response to receiving a confirmation reply from the second terminal, a collaborative browsing session is established between the first virtual character and the second virtual character.

5. The method according to claim 4, characterized in that, The collaborative browsing entry includes a first display style and a second display style; When no second virtual character that meets the preset collaboration conditions is detected, the collaborative browsing entry is displayed in the first display style; When at least one second virtual character that meets the preset collaboration conditions is detected, the collaborative browsing entry is displayed in a second display style, which includes displaying the number of second virtual characters that meet the preset collaboration conditions.

6. The method according to claim 4, characterized in that, The step of sending a collaborative browsing request to the second terminal in response to a trigger operation on the collaborative browsing entry includes: In response to the triggering operation of the collaborative browsing entry, multiple second virtual character identifiers that meet preset collaborative conditions are displayed; In response to a trigger operation on any of the second virtual character identifiers, a collaborative browsing request is sent to the second terminal corresponding to the selected second virtual character identifier.

7. The method according to claim 6, characterized in that, The method further includes: In response to selecting multiple second virtual character identifiers, a collaborative browsing request is sent to multiple second terminals corresponding to the selected multiple second virtual character identifiers; In response to receiving confirmation responses from the plurality of second terminals, a collaborative browsing session is established between the first virtual character and the plurality of second virtual characters; The second window includes multiple windows, each of which is used to display the browsing content of the corresponding second virtual character in browsing mode.

8. The method according to claim 1, wherein determining the display format of the first window and / or the second window provided by the graphical user interface of the current terminal based on the behavioral state comprises: When both the first virtual character and the second virtual character are in browsing mode, the first window and the second window are displayed in the graphical user interface in a first display mode. When browsing, the second window is used to display the browsing content of the second virtual character.

9. The method according to claim 8, characterized in that, The method further includes: In response to a window display layout adjustment operation, the display area ratio between the first window and the second window is adjusted.

10. The method according to claim 8, further comprising: When the behavior state of the second virtual character changes from browsing state to non-browsing state, the second window is switched from the first display mode to the status indicator display mode; When not in browsing mode, the second window is used to display the behavioral status information corresponding to the second virtual character.

11. The method according to claim 10, characterized in that, The method further includes: When the behavior state of the second virtual character changes from non-browsing state to browsing state, the second window is restored to the first display mode.

12. The method according to claim 8, further comprising: When the behavior state of the first virtual character changes from browsing state to non-browsing state, the first window is switched to a hidden state; The second window is switched from the first display mode to the second display mode, wherein the display area corresponding to the second display mode is smaller than the display area corresponding to the first display mode.

13. The method according to claim 12, characterized in that, The method further includes: When the second window switches to the second display mode, an expand control is provided in the second window; In response to a trigger operation on the expanded control, the second window is restored to the first display mode.

14. The method according to claim 12, characterized in that, The method further includes: When the second window switches to the second display mode, a hidden control is provided in the second window; In response to a trigger operation on the hidden control, the second window is switched to a hidden state; Switch the hidden control to be displayed as a restore control; In response to a trigger operation on the recovery control, the second window is restored to the second display mode.

15. The method according to claim 12, characterized in that, The method further includes: In response to a long press and drag operation on the second window, adjust the position of the second window in the graphical user interface.

16. The method according to claim 1, characterized in that, The method further includes: Receive target filtering conditions; After the collaborative browsing session is established, monitor whether there are any virtual items that meet the target filtering conditions in the browsing content of the second virtual character in the browsing state; When a virtual item that meets the target filtering criteria is detected, the second window is also used to display a corresponding prompt.

17. The method according to claim 16, characterized in that, The target filtering criteria include the target virtual item identifier and the corresponding price range.

18. The method according to claim 17, characterized in that, The browsing content includes virtual items. When a virtual item that meets the target filtering criteria is detected, the second window is further used to display a corresponding prompt, including: In response to the detection that the browsing content of the second virtual character contains the target virtual item corresponding to the target virtual item identifier, and the price of the target virtual item is within the corresponding price range, the identifier corresponding to the target virtual item is displayed in the second window with a prominent visual effect.

19. The method according to claim 16, characterized in that, The method further includes: When a virtual item that meets the target filtering criteria is detected, if the second window is hidden, a prompt message associated with the target virtual item is displayed in the graphical user interface.

20. The method according to claim 19, characterized in that, The method further includes: In response to a triggering operation for the prompt message, a details page for the target virtual item is displayed, and the details page is used to perform transaction processing for the target virtual item.

21. The method according to claim 19, characterized in that, The method further includes: The notification message includes the addition of a control; In response to the triggered operation for the added control, the target virtual item is added to the purchase queue.

22. The method according to any one of claims 1-18, characterized in that, The method further includes: In response to a selection operation on the browsing content displayed in the second window, detailed information of the target content is displayed; and / or, Perform transaction processing for the target content.

23. An information processing device, characterized in that, The device includes: A session establishment module is used to establish a collaborative browsing session between a first virtual character and at least one second virtual character, wherein the first virtual character is controlled by the current terminal, and the second virtual character includes virtual characters controlled by the second terminal and / or uncontrolled virtual characters. The behavior monitoring module is used to monitor the behavior status of the first virtual character and / or the second virtual character, the behavior status including at least browsing status and non-browsing status; The display control module is used to determine the display format of the first window and / or the second window provided by the graphical user interface of the current terminal according to the behavior state, wherein the first window is used to display the browsing content of the first virtual character in the browsing state, and the second window is used to display the browsing content or behavior state information of the second virtual character in the browsing state according to the behavior state of the second virtual character.

24. An electronic device, characterized in that, include: Memory stores computer-executable instructions that can be executed by a processor; A processor for executing the computer-executable instructions to implement the method as claimed in any one of claims 1-22.

25. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1-22.

Images