Virtual stall interaction method and device, electronic equipment and storage medium

Abstract

An embodiment of the present disclosure provides a virtual stall interaction method, comprising: providing a specific stall area in a graphical user interface of a game scene; triggering an interaction control mode of a controlled virtual object in response to a controlled virtual character entering the specific stall area; in the interaction control mode, controlling the controlled virtual character to perform an adsorptive displacement in the specific stall area to move to a target stall in response to a displacement input instruction acting on the controlled virtual character; determining at least one target stall associated with a position of the controlled virtual character in the specific stall area according to the position of the controlled virtual character in the specific stall area, and obtaining associated information of the at least one target stall; and displaying the associated information in the graphical user interface.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to virtual booth interaction methods, apparatus, electronic devices, and storage media. Background Technology

[0002] In related virtual scene interaction technologies, to enable sequential browsing of multiple information publishing nodes, controlled virtual objects typically need to approach each target node one by one and perform a click-and-select interaction to trigger a graphical user interface that displays the corresponding information list window. After browsing is complete, the window is closed and the user moves to the next node, and this process is repeated to complete the viewing. For example, in a multi-user online virtual environment transaction scenario, to enable browsing of multiple stalls, the above-mentioned interaction method of clicking one by one and bringing up a details window is often used.

[0003] However, in the above scheme, the controlled virtual object needs to frequently perform proximity, selection, browsing, and closing operations based on the interactive logic of triggering information windows one by one. This results in the terminal needing to process touch event responses and interface element creation and destruction instructions at a high frequency, increasing the processor's computational load and rendering pipeline resource overhead. Especially in scenarios with densely distributed information nodes, frequent interface switching exacerbates the fluctuation of the terminal's rendering load, and manual precise selection of small controls is prone to accidental touches, reducing information acquisition efficiency. Summary of the Invention

[0004] This disclosure provides a virtual booth interaction 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, a virtual stall interaction method is provided, which provides a graphical user interface (GUI) via a terminal device. The GUI displays at least a portion of a game scene, and the game scene includes a controlled virtual character controlled by the terminal device. The method includes: providing a specific stall area in the GUI of the game scene; triggering an interactive control mode for the controlled virtual character when the controlled virtual character enters the specific stall area; in the interactive control mode, controlling the controlled virtual character to perform an adsorption-like displacement within the specific stall area to move to a target stall in response to a displacement input command acting on the controlled virtual character; determining at least one target stall associated with the location based on the position of the controlled virtual character within the specific stall area, and obtaining association information of at least one target stall; and displaying the association information in the GUI.

[0006] According to one aspect of this disclosure, a virtual stall interaction device is provided, which provides a graphical user interface (GUI) via a terminal device. The GUI displays at least a portion of a game scene, and the game scene includes a controlled virtual character controlled by the terminal device. The device includes: an area providing module for providing a specific stall area in the GUI of the game scene; an interaction control module for activating an interaction control mode for the controlled virtual character when it enters the specific stall area; a movement control module for controlling the controlled virtual character to perform a suction-type displacement within the specific stall area to move to a target stall in response to a displacement input command acting on the controlled virtual character in the interaction control mode; an information determination module for determining at least one target stall associated with the location based on the location of the controlled virtual character within the specific stall area, and obtaining associated information of at least one target stall; and an information display module for displaying the associated information in the GUI.

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

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

[0009] One embodiment of this disclosure provides a virtual stall interaction method, comprising: providing a specific stall area in a graphical user interface of a game scene; triggering an interaction control mode for the controlled virtual object in response to a controlled virtual character entering the specific stall area; in the interaction control mode, controlling the controlled virtual character to perform a suction-type displacement within the specific stall area to move to a target stall in response to a displacement input command acting on the controlled virtual character; determining at least one target stall associated with the location based on the position of the controlled virtual character within the specific stall area, and obtaining association information of at least one target stall; and displaying the association information in the graphical user interface. This reduces the interaction path length and terminal operation command redundancy in virtual stall browsing scenarios, helps reduce the impact of frequent interface switching on terminal rendering processing overhead, improves the efficiency of acquiring virtual product information, and reduces the computational load during the frequent creation and destruction of interface elements on the terminal side. 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 virtual booth interaction method in one exemplary embodiment of this disclosure is shown. Figure 3 A schematic diagram of the interface of the virtual booth interaction method in one exemplary embodiment of this disclosure is shown. Figure 4 A schematic diagram of the interface of the virtual booth interaction method in one exemplary embodiment of this disclosure is shown. Figure 5 This diagram illustrates the structure of a virtual booth interaction device in one exemplary embodiment of the present disclosure. Figure 6 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

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

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

[0015] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0016] Figure 1A system architecture diagram of the operating environment of this embodiment is shown. This system architecture may include a first client 110, a second client 120, and a server 130. The first client 110 and the second client 120 are terminal devices that have installed and run game client programs, such as mobile phones, tablets, personal computers, smart wearable devices, game consoles, etc. They have display functions and can display a graphical user interface, which may include the operating system interface or the application interface. The first client 110 is the client used by the first game account, and the second client 120 is the client used by the second game account; that is, the game client program running on the first client 110 is logged into the first game account, and the game client program running on the second client 120 is logged into the second game account. The server 130 generally refers to the backend system providing game services in this exemplary embodiment; it can be a single server or a cluster of multiple servers. A game server program is deployed on the server 130 to perform server-side game data processing. The first client 110, the second client 120, and the server 130 can be connected via wired or wireless communication links for data transmission. For example, the first client 110 can send information to the second client 120 through the server 130, and the second client 120 can send information to the first client 110 through the server 130. Furthermore, the first client 110 and the second client 120 can also communicate directly via wired or wireless means.

[0017] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be based on the aforementioned system architecture. Various cloud applications can run under the cloud interaction system, such as cloud gaming. Taking cloud gaming as an example, cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operating mode, the game program's execution and the game screen presentation are separated. The storage and execution of in-game control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 130). The cloud gaming client (such as the aforementioned first client 110 and second client 120) includes receiving and sending data, as well as 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 or editing, the player 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 game screen data, returns it to the cloud gaming client via the network, and finally decodes and outputs the game screen through the cloud gaming client.

[0018] To make the above-mentioned objectives, features and advantages of this disclosure more apparent and understandable, the disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] According to one embodiment of the virtual booth interaction method of this disclosure, a graphical user interface is provided through a terminal device. The graphical user interface displays at least a portion of a game scene, and the game scene includes a controlled virtual character controlled through the terminal device, such as... Figure 2 As shown, the method may include: Step S210: In the graphical user interface of the game scene, a specific stall area is provided; Step S220: In response to the controlled virtual character entering a specific booth area, an interactive control mode for the controlled virtual object is triggered. Step S230: In interactive control mode, in response to the displacement input command acting on the controlled virtual character, the controlled virtual character is controlled to perform an adsorption displacement within a specific stall area to move to a target stall. Step S240: Based on the location of the controlled virtual character within a specific stall area, determine at least one target stall associated with the location, and obtain the association information of at least one target stall; Step S250: Display the associated information in the graphical user interface.

[0020] According to one embodiment of this disclosure, reducing the interaction path length and terminal operation command redundancy in the virtual stall browsing scenario helps to reduce the impact of frequent interface switching on terminal rendering processing overhead, improve the efficiency of obtaining virtual product information, and reduce the computational load during the frequent creation and destruction of interface elements on the terminal side.

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

[0022] In step S210, a specific stall area is provided in the graphical user interface of the game scene. In this way, by clearly defining the spatial boundaries of interaction in the game scene, a physical anchor point is provided for automatically triggering the precise adsorption mode, and the system only needs to perform stall detection and information push within this area, which significantly reduces computational overhead and attention distraction.

[0023] For example, in the central city scene presented in the graphical user interface of a large-scale massively multiplayer online role-playing game, the developers pre-defined a virtual area on the east side of the plaza, divided into a regular matrix, as a specific stall area via a server-side map configuration module. This area can be displayed on the player's device screen with a semi-transparent blue overlay, or it can be dynamically highlighted on the minimap with a gold dashed border only when the player approaches, thus clearly indicating to the player controlling the virtual character that there is a functional space with specific interactive logic within the current scene.

[0024] Optionally, the aforementioned specific stall area is used to identify functional spaces where players can set up stalls and browse stalls, and its boundaries are dynamically updated by the server based on real-time stall data. Optionally, the aforementioned specific stall area can be a set of functional spaces dynamically divided by the server based on real-time stall data within the current scene. Considering the highly dynamic and temporary nature of player stall arrangements in multiplayer online games, as a possible implementation, the server can maintain a two-dimensional marker table aligned with the scene map coordinates. Each cell in this table corresponds to a standard grid unit in the scene. When a virtual stall successfully set up by a player exists within a certain grid unit, the server marks that cell as occupied, and all consecutive or discrete cells marked as occupied together form the aforementioned specific stall area. The boundary of this area does not need to be continuously presented as a fixed visual element on the player's graphical user interface. Instead, it can be temporarily displayed only when the player-controlled virtual character enters a certain buffer range outside the area, in the form of a fade-in boundary light effect or a minimap highlight, to avoid unnecessary interface elements interfering with the game screen outside the stall area.

[0025] Optionally, in one implementation, the aforementioned specific stall area can be logically further subdivided into multiple stall sub-areas, each corresponding to a minimum grid unit that can be exclusively used by a single player. Furthermore, to avoid area boundary jitter caused by frequent player logins / logouts or stall closures, the server can introduce a time delay buffering mechanism when updating the composition range of a specific stall area. For example, when a player closes their stall within a grid unit, the cell is not immediately removed from the specific stall area, but enters a suspended state lasting 30 to 120 seconds. During this suspended state, if the original player reopens their stall or a new player joins, the cell remains part of the specific stall area; if the suspended state times out and no new stall joins, the server releases the cell from the area marker. This effectively reduces the topology data refresh pressure on the client caused by frequent changes in area boundaries, and also prevents players briefly closing their stalls to restock from causing interaction interruptions for players browsing adjacent stalls.

[0026] In step S220, in response to the controlled virtual character entering a specific stall area, an interactive control mode for the controlled virtual character is triggered. In this way, by automatically triggering the interactive control mode upon entering a specific stall area, players can seamlessly enter the stall browsing process without manually switching, reducing operational interruptions and allowing scene exploration and product browsing to proceed in parallel, significantly improving the continuity of interaction and immersion.

[0027] In one implementation, the virtual character controlled by the player walks along the main city street. When the character steps into the boundary of a stall area consisting of multiple stall grids, the system detects the entry event and immediately switches the currently used free movement mode to an interactive control mode specifically for browsing stalls. At this time, a mode switching prompt icon automatically appears in the graphical user interface, and the corresponding dedicated control controls are loaded in the operation area, indicating that the player is now in a stall browsing state. The player does not need to perform any manual activation action; the operation mode is automatically activated simply by stepping into the area, laying the foundation for seamless switching for subsequent direct browsing of stalls within the area.

[0028] Optionally, the aforementioned interactive control mode is used to automatically activate in response to an entry event, switch the input mapping relationship, and enable the exclusive interactive functions of the stall area. Optionally, the aforementioned interactive control mode can be a composite operation state pre-configured for a specific stall area, which is automatically activated in response to a controlled virtual character entering the area. In one possible implementation, the interactive control mode includes a first sub-state for movement operations and a second sub-state for product browsing. When the controlled virtual character steps into the boundary of a specific stall area, the system determines that an entry event has occurred by detecting the collision relationship between the character's foot anchor point and the area boundary box, and then switches the input mapping relationship of the terminal device from free pathfinding logic to grid snapping logic, and presents the corresponding control controls in the graphical user interface, such as a virtual joystick or directional keyboard that floats out in a semi-transparent manner. It should be noted that the above division of sub-states within the mode is only one example, and this disclosure is not intended to limit the specific connotation of the interactive control mode. In actual implementation, it can also be configured as a single state or a multi-level nested state according to the terminal type or player preferences.

[0029] Optionally, considering the objective differences in input hardware across different terminal devices, the representation of the aforementioned interactive control mode in the graphical user interface and its triggered function mapping can be configured differently. As one possible implementation, on a mobile terminal with a touchscreen, after the interactive control mode is activated, a virtual joystick control can be permanently displayed in the lower right corner of the graphical user interface, with its eight-way input mapped to a snap-to-grid displacement command. On a PC terminal equipped with a keyboard, the same interactive control mode can be configured to respond to inputs from physical directional keys or WASD keys (i.e., standard keyboard movement control keys), using the same snap-to-grid logic to control the movement of the controlled virtual character between stalls. Furthermore, to prevent players from accidentally switching modes when entering the stall area without intent, a manual locking control can be provided on the side of the graphical user interface. Players can trigger this control to temporarily disable automatic entry detection; this embodiment does not limit this aspect.

[0030] One objective of this embodiment is to avoid the operational burden caused by players frequently switching modes manually during high-speed movement scenarios such as combat and map exploration by binding the activation conditions of the interactive control mode to the spatial position of the controlled virtual character. Furthermore, it allows for the immediate loading of the interaction protocol adapted to the area the moment the player enters the stall area, reducing the experience disruption caused by interface transitions. To prevent frequent mode changes due to network latency or coordinate jitter causing the character to repeatedly enter and exit the area boundary, the triggering process can specifically include: when the controlled virtual character's current coordinates first enter the bounding rectangle of a specific stall area, the mode is not immediately switched; instead, a dwell timer of a preset duration (e.g., 0.5 to 1.5 seconds) is started. If the character's coordinates remain within the area until the timer expires, the activation event of the interactive control mode is formally triggered; otherwise, it is considered an invalid traversal. In other words, the entry determination relies not only on instantaneous coordinates but also on a continuous spatial dwell state, thereby improving the stability of mode switching.

[0031] Optionally, the aforementioned controlled virtual character refers to a virtual entity that is manipulated by the player in real time through a terminal device, and serves as the detection subject for spatial entry events. Optionally, the aforementioned controlled virtual character can be any class avatar that the player is currently logged into and manipulating in a multiplayer online game, and its manifestation includes, but is not limited to, virtual images such as humanoid characters, animal mounts, mechanical vehicles, or floating sprites. It should be noted that the specific appearance, faction affiliation, or equipment appearance of the controlled virtual character does not affect the judgment logic of the aforementioned entry event; as long as the preset anchor point of the virtual image (such as the center point of the foot or the geometric center of the collision body) intersects with the spatial boundary of the specific booth area, it is considered to meet the entry conditions. In different operating phases, the controlled virtual character can be in various action states such as standby, walking, running, or riding. The trigger judgment of the aforementioned interactive control mode can further take into account this action state: if the character is in an uninterruptible flying or teleporting state, even if the coordinates enter the area, the mode switch will not be triggered temporarily until the current action state returns to a controllable ground walking state. This embodiment of the disclosure does not limit this.

[0032] In step S230, in interactive control mode, in response to a displacement input command applied to the controlled virtual character, the controlled virtual character is controlled to perform a magnetic displacement within a specific stall area to move to a target stall. This converts the player's displacement input command into a grid-level magnetic displacement, avoiding boundary violations and accidental touches caused by pixel-level micro-operations, making stall browsing movement more efficient and in line with mobile touch habits. In one implementation, when the player-controlled character enters a specific stall area in the trading square, a joystick control automatically unfolds on the side of the interface and becomes the currently used displacement control method. The player places their finger on the touch point of the virtual joystick and drags it upwards. The system immediately interprets this eight-directional input as an upward grid offset command; subsequently, instead of moving gradually through continuous coordinate interpolation, the character instantly teleports from the current grid center to the grid center of the adjacent stall directly above, completing a magnetic displacement. If the player continues to input in that direction without releasing the key, the system will repeat the upward suction at fixed intervals, and the character will pass through the second and third stalls in sequence until the player releases the touch point or reaches the boundary of the area. Each time the suction is completed, the product floating window on the side of the interface will be refreshed in real time with the associated information of the target stall, so that the browsing process can be carried out continuously without any click confirmation.

[0033] Optionally, the displacement input command is used to initiate a directional movement request to the controlled virtual character, driving the character to perform an adhesive displacement within a specific booth area. Optionally, the specific acquisition method of the above displacement input command can be configured in various ways according to the hardware characteristics of the terminal device. As one possible implementation, on a mobile device with a touchscreen, the displacement input command can be generated by monitoring touch events on the virtual joystick control displayed in the graphical user interface; for example, when a player presses their finger on the joystick touch area and drags it in the desired direction, the system calculates the offset vector of the touch point relative to the origin of the joystick in real time, and then maps this vector into a directional signal with a clear directionality. In another implementation, when the player uses a PC device with a physical keyboard, the displacement input command can also be generated by listening to the pressing state of the arrow keys or the WASD (forward, backward, left, right) key group. It should be noted that regardless of whether the command originates from a touchscreen gesture or a keyboard key, it must ultimately be standardized by the system into a control signal containing displacement direction information; this disclosure does not limit the specific signal acquisition hardware form.

[0034] Optionally, to reduce the repetitive operation burden on players when browsing multiple adjacent stalls, the aforementioned displacement input commands can be configured to support a continuous triggering mode in their activation logic. That is, when the system detects that a player continuously receives or maintains input signals in the same direction for a short period, it can determine this as a continuous displacement request and periodically generate displacement input commands in the same direction according to a preset time or distance cycle, thereby controlling the controlled virtual character to continuously traverse multiple grid units. For example, if the player drags the joystick upwards and holds it, the character will automatically and sequentially attach to the first, second, and even third stall directly above, without requiring the player to click or drag repeatedly. Furthermore, the system can also introduce a rate-increasing mechanism during this continuous triggering process. Initially, grid jumps are performed at a slower frequency to allow the player to confirm the first target, while the frequency of attachment switching gradually increases after the input is maintained for more than a preset duration, balancing the needs of both detailed browsing and rapid traversal.

[0035] Optionally, the suction-type displacement aims to lock the landing point of the controlled virtual character at the center coordinates of the stall grid, replacing the continuous trajectory of pixel-level free sliding with a jump-type segment. Optionally, considering that in densely arranged stall areas, if a continuous coordinate interpolation movement method is used, the player is very likely to cause the character to overshoot the target position due to insufficient joystick control precision or release timing deviation, this embodiment uses suction-type displacement to achieve forced grid constraint on the landing point. Specifically, after receiving the displacement input command, the system does not directly drive the character to move continuously at the pixel level in that direction, but first calculates the target grid coordinates in the preset grid coordinate system based on the grid coordinates currently occupied by the controlled virtual character and the direction indicated by the command; then, the system directly updates the character's position attribute to the center coordinates of the target grid, completing an instantaneous migration from one stall to an adjacent stall. That is to say, no matter how the pressure or duration of the original input signal changes, the character will eventually stand precisely at the preset landing point of the target grid, thus completely eliminating the overshoot phenomenon, allowing the player to complete precise movement between stalls on the small screen of the mobile device without tedious micro-operation correction.

[0036] Optionally, the preset grid coordinate system upon which the aforementioned adsorption displacement relies can be flexibly set according to the scene layout of a specific stall area. Besides using a uniformly distributed square grid array to adapt to regularly arranged plaza-type trading areas, rectangular or fan-shaped partitioned grids can also be used for narrow passages or circular markets, ensuring that the grid boundaries match the road directions and landscape obstructions within the scene. It should be noted that the size parameters of each grid unit are not fixed; they can be set to 80×80 pixel virtual units based on screen resolution and stall model size, or dynamically adjusted according to the camera's zoom level to ensure good alignment between the stall and the grid at every visual level. In actual implementation, the system can load the grid topology configuration file corresponding to the specific stall area when the player triggers the interactive control mode, thus ensuring that the adsorption landing point is accurately mapped to the valid coordinates of each stall entity.

[0037] Optionally, to cover the player's multi-angle browsing path in the stall area, the aforementioned suction displacement can also support grid jump logic in eight neighboring areas. Specifically, taking the grid where the controlled virtual character is currently located as the origin, the system establishes a coordinate offset system including up, down, left, right, and four diagonal directions. When a displacement input command is received as diagonal, the system interprets it as a grid unit offset along two axes simultaneously. For example, the target grid in the upper right direction corresponds to a row index minus 1 and a column index plus 1, thereby controlling the character to move to the stall diagonally in front. It should be understood that for the target grid pointed to by the diagonal direction, the system can further verify whether the grid is in a valid occupied state before executing the suction displacement. If there is no stall entity currently existing in the grid, the system can refuse to execute this diagonal suction, or automatically correct this displacement to the nearest valid stall in the horizontal and vertical directions, thereby preventing the player from accidentally entering an empty area and interrupting the continuity of browsing the stalls.

[0038] Optionally, the target stall is the target grid unit reached by the controlled virtual character after completing the suction displacement, and it is used to associate and display the corresponding stall's product information. Optionally, the above-mentioned target stall determination process is strictly bound to the grid landing point of the controlled virtual character, rather than relying on the player's precise selection operation on the stall model or stall owner. Specifically, when the system moves the character to a preset grid through suction displacement, the stall entity registered in that grid is automatically identified as the current target stall, and the associated information of the stall is loaded for presentation in the preset display area of ​​the graphical user interface. Furthermore, if the grid the character falls into is currently unoccupied, the system can mark the grid as empty coordinates. At this time, even if the character has completed suction and landing, no stall information display request will be triggered, thereby avoiding invalid interaction. In addition, the associated information of the target stall may include, but is not limited to, virtual product name information, virtual product price information, virtual product icon information, and virtual product inventory status, and this information can be dynamically refreshed as the character switches between different target stalls, ensuring that the player can obtain a real-time product overview without opening a separate transaction window.

[0039] In an optional implementation, in interactive control mode, stalls within a specific stall area are arranged according to a preset grid. This regular arrangement of stalls using the preset grid provides discretized coordinate anchor points for the eight-way joystick input mapping and significantly reduces the operational burden on players to precisely navigate to specific stalls.

[0040] In one implementation, when a controlled virtual character enters a specific stall area and triggers the interactive control mode, the system arranges the various player stalls within that area according to a preset grid. Each stall occupies one and only one grid cell, forming an equally spaced row and column matrix in the scene space. For example, a grid coordinate system is established with the southwest corner of the stall area as the origin. A column dividing line is set every first preset distance along the horizontal direction, and a row dividing line is set every second preset distance along the vertical direction. Stall A is assigned to the grid cell in the 2nd row and 3rd column, and stall B is assigned to the grid cell in the 2nd row and 4th column. The server maintains a mapping table between each grid cell and the stall identifier to ensure that each grid cell is associated with at most one valid stall.

[0041] Optionally, a preset grid is used to arrange stalls within a specific stall area into a regularized row and column array to provide a discretized spatial reference. Optionally, the preset grid can be a regularized coordinate array generated based on stall distribution data maintained by the server. In practical applications, a specific stall area is divided into multiple grid units of equal or unequal size, each grid unit having a unique row and column identifier in the coordinate system. When the server detects a player initiating a stall request, it automatically allocates the stall to an available grid unit based on the current grid occupancy status and records the grid unit as occupied. Each grid unit corresponds to a specific coordinate range in the scene space, such as a rectangular area with a horizontal span of 80 pixels and a vertical span of 80 pixels, so that the stalls located within this grid unit have a definite display boundary in the graphical user interface. It should be noted that the above 80 pixel units are only an example. In actual implementation, the size of the grid unit can be dynamically adjusted according to factors such as the screen resolution of the terminal device, the scaling ratio of the graphical user interface, and the visual presentation scale of the stall. This disclosure is not limited to this.

[0042] Optionally, considering the differences in interaction density across different game scenarios, the layout of the preset grid can also be diversified. As one possible implementation, in densely populated main city commercial areas, the preset grid can adopt a strict rectangular array layout, with each grid unit corresponding to one stall, and adjacent grid units maintaining a uniform spacing to form a visually neat sequence. In contrast, in sparsely distributed border markets, the preset grid can adopt a non-uniform hexagonal honeycomb layout, allowing the width of the passageways between stalls to adapt to the terrain. Besides differences in geometric shape, the hierarchical division of grid units can also differ. For example, in a large trading plaza, a primary grid can be set up to divide the area, and secondary sub-grids can be set within each primary grid to precisely locate individual stalls. In other words, the preset grid is not limited to a single-level row and column matrix, but can be nested according to the complexity of the scene; this disclosure does not impose any limitations on this.

[0043] Optionally, to ensure that the controlled virtual character can move quickly and accurately to the target stall based on joystick input, a clear mapping relationship needs to be established between the preset grid and the scene coordinates. In one specific implementation, the server maintains a grid index table, which records the world coordinates of the center point of each grid cell, the boundary coordinates of the four vertices, and the currently bound stall identifier. When the player enters the interactive control mode through the graphical user interface, the client obtains at least part of the data from the grid index table from the server and constructs a grid coordinate system locally. Further, in the grid coordinate system, with the grid cell where the controlled virtual character is currently located as the center, the eight adjacent grid cells around it correspond to the eight directions of joystick input. It should be understood that if an adjacent grid cell is in an idle state (i.e., not bound to a valid stall), when the joystick input points in that direction, the controlled virtual character can either remain stationary or move to the idle grid cell to wait. The specific displacement strategy can be set according to the game design requirements, and this embodiment does not limit it.

[0044] Figure 3 A schematic diagram of the interface of a virtual booth interaction method in one exemplary embodiment of this disclosure is shown.

[0045] In an optional implementation, the controlled virtual character performs a suction-type displacement within a specific stall area, including: mapping the displacement direction indicated by the displacement input command to a coordinate offset in a preset grid coordinate system centered on the current position of the controlled virtual character; and controlling the controlled virtual character to suction-type move to the target stall based on the coordinate offset. In this way, by mapping the direction input to grid coordinate offset and driving suction-type positioning, the movement control precision is simplified from pixel-level to grid-level, significantly reducing the operational burden. It also allows the character to accurately stop at the target stall, effectively avoiding overstepping or accidental touches during manual free movement.

[0046] In one implementation, after the player controls a virtual character to enter a specific stall area and activates the interactive control mode, they place the touch point within the virtual joystick control area and slide it upwards. The system maps the upward direction indicated by this displacement input command to a preset grid coordinate system centered on the character's current grid location, generating an upward coordinate offset. This allows the character to automatically move to the center of the adjacent stall directly above it via an adsorption mechanism. If the player continues to slide upwards, the system responds to continuous inputs in the same direction, controlling the character to sequentially switch between multiple adjacent stalls upwards. Each movement automatically adsorbs to the center of the corresponding grid until the player releases the joystick or reaches the area boundary.

[0047] Optionally, the aforementioned displacement input command is used to receive directional control input from the player for the controlled virtual character, triggering the generation of coordinate offset and subsequent magnetic movement. Optionally, the aforementioned displacement input command can be triggered by the player through various human-computer interaction methods to explicitly indicate the desired displacement direction of the controlled virtual character to the system. In one embodiment, the player can generate the displacement input command by operating a virtual joystick control in the graphical user interface; specifically, such as... Figure 3 As shown, when a player places a touch point within the control area of ​​the virtual joystick and drags it in a specific direction, the system identifies one of the eight displacement directions based on the vector offset of the touch point relative to the joystick's center point. This could be an upward, upper-left, or lower-right component, which is then used to generate a corresponding displacement input command. In another implementation, particularly on a personal computer, the player can generate the aforementioned displacement input command by pressing the arrow keys or the up, left, down, and right control keys on the keyboard. A single press or a long press can be recognized by the system as a continuous input in the same displacement direction. It should be noted that the aforementioned displacement input command is not limited to joystick or keyboard operations; it can also be a swipe gesture, touchpad directional input, or other equivalent directional control signals.

[0048] Optionally, considering that players may frequently switch browsing directions or quickly traverse multiple stalls along the same straight line while browsing stalls, the response mechanism for the aforementioned displacement input commands can also be configured with input buffering and direction recognition optimization strategies. Specifically, when the system detects that the player has two consecutive directional inputs or diagonal directional components within a very short time window, it can determine the final single main direction according to preset priority rules to avoid unexpected diagonal movements caused by touch jitter or operational inertia. In addition, to prevent players from accidentally triggering the grid-based movement in combat or high-speed map traversal scenarios, the system can also perform mode interlocking processing on displacement input commands based on movement speed thresholds. That is, when the movement speed of the controlled virtual character exceeds a preset limit, the displacement input command is reverted to a regular free movement command instead of being mapped as grid-based displacement. In other words, displacement input commands do not always trigger grid-based movement in a fixed way, but can be dynamically identified and differentiated according to the current system mode or movement state.

[0049] Optionally, the aforementioned preset grid coordinate system is used to structurally index the stall locations within the stall area, determining the grid offset with the character's current position as the reference center. Optionally, the aforementioned preset grid coordinate system can be constructed based on the actual stall layout within a specific stall area. Considering that the stall system typically needs to meet the requirement of multiple players displaying goods in the same area, the stalls within this area can be arranged in a strict tabular form, with each grid position uniquely corresponding to a stall or vacant position. In the aforementioned coordinate system, the grid position currently occupied by the controlled virtual character is used as the dynamic origin. Whenever the character successfully attaches to a new target stall, the origin of the coordinate system is immediately updated to the grid center where the character's new position is located. For example, if the character is currently located at coordinates (2,3), then the adjacent grids directly above, below, to the left, to the right, and along the four diagonal directions correspond to coordinates (2,4), (2,2), (1,3), (3,3), (1,4), (3,4), (1,2), and (3,2), respectively. It should be noted that the axial division, grid density, and coordinate representation of the above grid coordinate system can be adaptively adjusted according to the specific scene size and number of stalls, and are not limited to a two-dimensional Cartesian coordinate form.

[0050] Optionally, to ensure a high degree of consistency between the grid coordinate system and the actual stall distribution in the scene, the aforementioned coordinate system can be dynamically generated based on the stall occupancy status stored on the server during initialization or updating. Specifically, when the server receives a player's request to set up a stall at a certain grid location, it marks that location as occupied and synchronously refreshes the occupancy marker in the grid coordinate system on all clients entering that specific stall area. Thus, when a player moves within the grid coordinate system, the system can query the occupancy status of the target grid in real time. If a valid stall exists in the target grid, the system controls the character to move to that location and triggers the display of associated information; if the target grid is empty, the character can remain at that location or skip the empty space according to preset rules and continue moving forward. Furthermore, considering that some stall areas may have irregular shapes or obstacle areas, the aforementioned grid coordinate system can also support local grid disabling settings, such as setting movement barriers at grid locations corresponding to impassable areas to prevent characters from abnormally attaching to invalid locations.

[0051] Optionally, the aforementioned adsorption-type movement is used to control the character to automatically fall to the target stall based on the coordinate offset, thereby reducing the requirements for operational precision.

[0052] Optionally, the aforementioned suction-type movement aims to reduce the precision of movement control for the controlled virtual character from pixel-level precision under manual player operation to grid-level precision. In one implementation, after the system determines the coordinate offset based on the displacement input command, it does not simply propel the character towards the target direction at a normal movement speed until the player releases their grip. Instead, it automatically calculates the path from the current grid center to the target grid center and drives the character along that path at a preset suction speed until it precisely stops at the geometric center of the target grid or a preset landing point. During this process, the player does not need to make micro-management corrections to ensure that the character accurately stops in front of the stall, effectively avoiding the phenomenon of frequently overshooting the target or failing to align with the stall due to insufficient precision in manual control. It should be noted that the suction speed can be configured as uniform movement or variable-speed movement with a easing effect according to the needs of the scene. The purpose is to ensure the visual clarity of position switching, so that the player can clearly perceive that the character is moving from one stall to an adjacent stall.

[0053] Optionally, in addition to single-move snap-in, the system can also respond to continuously received displacement input commands to control the virtual character to perform multiple grid movements consecutively. Specifically, when the player holds down the up arrow key or continuously drags the virtual joystick in the same direction, after reaching the first target stall and making a brief stop or without stopping, the character continues to automatically calculate the next adjacent target grid based on the same coordinate offset direction, and sequentially performs continuous snap-in movements until the player releases the input control or reaches the physical boundary of a specific stall area. This continuous snap-in mechanism allows players to quickly scan a column or row of stalls without having to repeat a single input operation at each stall. Furthermore, during continuous snap-in, the system can also differentiate the dwell time at each intermediate stall, whether to trigger the display of related information, and the transition method of the movement animation. For example, it can focus all attention on the stall where the character finally stops, while fading or quickly rotating the preview information of the stalls passed through.

[0054] In an optional implementation, the method further includes: in response to continuously receiving displacement input commands in the same direction, controlling the controlled virtual character to continuously perform multiple displacements in a preset grid coordinate system, so as to move sequentially to multiple adjacent target stalls. In this way, players can quickly traverse multiple consecutively arranged stalls by maintaining continuous directional input, significantly reducing repetitive triggering operations and improving the continuity and efficiency of stall browsing.

[0055] In one example, when the player's controlled virtual character is in the interactive control mode of a specific stall area, if the player continuously applies an upward displacement input command via the joystick without interruption, the system responds to the continuously received same directional command and controls the controlled virtual character to continuously perform multiple displacements in a preset grid coordinate system, moving upwards from the current grid cell one by one and stopping at multiple adjacent target stalls. During this process, the player does not need to initiate a single directional input again.

[0056] Optionally, the continuous reception determination of the aforementioned displacement input command in the same direction is used to trigger a continuous displacement mechanism of the controlled virtual character in the grid coordinate system. Optionally, the detection logic for the continuous reception of displacement input commands in the same direction can take various forms. In one embodiment, when the player keeps their finger in contact with the screen in the touch joystick area and continuously slides upwards, or keeps the joystick offset in the upper range for more than a preset duration threshold, the system determines that it has continuously received an upward displacement input command. In another embodiment, when the player holds down the direction key on the physical keyboard, the system periodically receives displacement input commands in the same direction at a fixed frequency, which is also considered a continuous reception state. It should be noted that the above-mentioned method for determining the continuity of input is only one example, and this disclosure is not intended to limit it. In actual implementation, it can also be determined by detecting whether the joystick vector direction angle offset is within a preset range, or by detecting whether the touch point has not left the effective touch area.

[0057] Optionally, considering that players typically need to quickly browse multiple stalls arranged in a row when browsing stalls, requiring a new directional input for each movement would significantly increase the operational burden and disrupt the browsing rhythm. As a possible implementation, by recognizing the continuous state of the displacement input command rather than a single trigger, the player's fine-tuning intentions and continuous browsing intentions can be effectively distinguished, thus preventing unexpected character displacement due to accidental touches or short operations. Besides detecting continuous input through touchscreen joystick offset holding and keyboard directional key long presses, the aforementioned continuous reception state can also be determined by detecting the continuous same-direction deflection angle of the game controller joystick, the same-direction tilt holding of the mobile terminal's gravity sensor, etc., and this disclosure is not limited to these methods. Furthermore, the determination of the aforementioned continuous reception can also be correlated with movement speed parameters. For example, maintaining a first movement speed for the initial 500 milliseconds of continuous reception, and switching to a second movement speed after continuous reception exceeds 500 milliseconds, where the second movement speed is greater than the first movement speed, to achieve rhythm control of precise positioning followed by rapid traversal.

[0058] Optionally, the aforementioned multiple consecutive displacements can allow the controlled virtual character to stop at multiple adjacent stalls in sequence, thereby achieving continuous traversal of the stall browsing path.

[0059] Optionally, the above-mentioned sequential movement to multiple adjacent target stalls can be executed as a controlled virtual character continuously jumping in a grid-by-grid manner within the current grid coordinate system. For example, when the controlled virtual character is located in the grid cell at coordinates 3x3 and receives a continuous upward displacement input command, the character first moves to the first adjacent target stall in the 3x4 grid and pauses briefly. If the directional input continues, it continues moving to the second adjacent target stall in the 3x5 grid, and so on, until the command is interrupted or the grid boundary is reached. After each displacement, the system can trigger the refresh and display of the associated information of the target stall in a side floating window, allowing the player to obtain the product overview of each stall sequentially without manual interaction. It should be noted that the above-mentioned sequential stopping method is only one example, and this disclosure is not intended to limit the stepping strategy of continuous movement.

[0060] Optionally, to ensure the stability of interaction and player controllability during continuous movement, the aforementioned mechanism for multiple continuous displacements may also include interruption and boundary handling logic. Specifically, if player interruption input is detected during continuous movement, such as a finger leaving the joystick area or releasing a direction key, the controlled virtual character will stop immediately after completing the currently ongoing single grid displacement and will not continue to execute the next preset displacement, thereby ensuring that the player can stop the character at any time to locate the target stall. In addition, if the next adjacent grid cell pointed to by the continuous displacement input command in the same direction does not have a target stall, for example, the grid cell is empty or exceeds the boundary of a specific stall area, the controlled virtual character can stay in the grid cell where the last valid target stall is located, or in an alternative implementation, automatically turn to the next nearest grid cell in that direction that has a stall and attach to it. It should be understood that the above interruption and boundary strategies can be flexibly configured according to specific application scenarios, and this disclosure does not limit them.

[0061] In step S240, based on the location of the controlled virtual character within a specific stall area, at least one target stall associated with that location is determined, and the association information of at least one target stall is obtained. In this way, dynamic triggering of product information is achieved through the spatial association between the character's location and the stall, eliminating the need to repeatedly open separate windows, effectively reducing the interaction path length and maintaining the immersive continuity of scene browsing.

[0062] In practical applications, when a controlled virtual character stays on a grid node within a specific stall area, the system filters out a stall that is positionally associated with that coordinate as the target stall based on the spatial mapping relationship between its current coordinates and the stall distribution data within the area. It then retrieves the associated information, including the virtual product name, price, and icon, from the virtual transaction configuration data corresponding to that stall. If the character moves continuously to an adjacent grid through adsorption displacement, the above filtering and retrieval process is refreshed synchronously with the position change to ensure that the associated information corresponds to the stall it is currently in.

[0063] Optionally, the process of determining associated stalls based on the location of the controlled virtual character can include various spatial matching rules, aiming to quickly locate the target stall through coordinate association to trigger the acquisition of association information. Optionally, considering that stalls are usually neatly arranged in a preset grid within a specific stall area, when the controlled virtual character is in a certain grid cell, the above determination process can directly map the grid cell currently occupied by the character to a stall occupying the same grid, thereby identifying that stall as the target stall. It should be noted that the relationship between the grid cell and the stall can be one-to-one, or multiple stalls can be contained within a single grid cell and further distinguished by the character's orientation or secondary coordinates. In actual implementation, the system can traverse the stall configuration table, search for at least one record whose coordinate field matches the character's current coordinates, and extract the stall identifier from it as the target stall. This method can fully utilize the orderliness of the grid layout, ensuring the real-time and accuracy of stall determination, and is particularly suitable for scenarios with high-density stalls.

[0064] Optionally, besides direct matching via grid occupation, the above determination process can also be implemented through real-time distance calculation. Specifically, the system can calculate the Euclidean or Manhattan distance between the controlled virtual character and each stall within a specific stall area, and determine the closest stall as the target stall. To avoid frequent switching of the target stall due to the character being located between two stalls, the above process can also introduce a distance threshold as a stabilization condition. Only when the distance between a stall and the character is less than a preset threshold is the stall included in the candidate set, or the current target stall is maintained in the candidate set until the distance of another stall is significantly less than the current stall. One objective of this implementation is to accurately identify the stall most closely associated with the player's position in free placement scenarios that do not rely on strict grid alignment, thereby expanding the applicable scenarios of the solution.

[0065] Optionally, to ensure the stability of the aforementioned location association determination mechanism across different movement states, the method can be dynamically adjusted based on the movement speed or input method of the controlled virtual character. For example, when the character is in a joystick-based micro-management mode with low movement speed, the system can immediately re-execute the stall determination process after each grid jump to ensure the product preview follows the movement. When the character traverses the stall area at high speed by tapping the ground, the system can temporarily suspend the real-time determination logic until the character stops or slows down below a threshold. Furthermore, the determination process can also incorporate visual indicators of the stalls for filtering, prioritizing stalls with valid indicator arrows as candidate target stalls, or using the character's current orientation to assist in locking onto the target stall when multiple stalls are close together. This prevents information flickering and resource waste caused by frequent refreshes of target stalls during high-speed movement, and also ensures that the selected target stall has valid product data available for browsing.

[0066] Optionally, the associated information is used to present players with an overview of the virtual goods at the target stall. This information may include at least one of text, numerical values, and graphical content to support the dynamic display of the side floating window. Optionally, the associated information may include, but is not limited to, virtual goods name information, virtual goods price information, virtual goods icon information, and virtual goods inventory status. This associated information can originate from stall configuration data pre-issued by the server before the player enters the stall area, or it can be retrieved in real-time by the client after triggering the stall determination process. For example, once a target stall is determined, the system can read the name information of a virtual weapon, its corresponding virtual currency price information, the two-dimensional icon information matching the appearance of the virtual goods, and the remaining purchasable quantity inventory status information from the transaction data table corresponding to that stall, and package this information into a structured object and store it in the interface rendering buffer. Based on this approach, players can perceive the main parameters of the stall's goods in real-time while browsing the scene without actively opening a separate transaction window, significantly reducing the interaction layer and maintaining scene continuity.

[0067] Optionally, the content composition and presentation granularity of the associated information can be dynamically configured according to the application scenario or player preferences. As a possible implementation, it can also include auxiliary information such as the vendor's character name, vendor credit rating, or limited-time discount tags to enrich the player's purchasing decision-making basis. It should be noted that the aforementioned associated information can be displayed in the graphical user interface as a combination of static text and icons, a vertically scrolling product list, or even a secondary floating window that expands to display more detailed attribute descriptions when the player focuses on a particular product item. Furthermore, to adapt to terminal devices with different screen resolutions, the icon size and text font size in the associated information can be adaptively scaled to ensure good readability on both mobile phone portrait screens and PC widescreen screens. In this way, by flexibly expanding the dimensions of the associated information content and its display format, the information disclosure needs of different types of virtual transaction scenarios can be met without modifying the core architecture.

[0068] In an optional implementation, at least one target stall associated with the controlled virtual character's location within a specific stall area is determined. This includes determining at least one target stall based on the distance between the controlled virtual character and each stall within the specific stall area. By introducing a distance parameter as a quantitative basis for stall association, the selection of target stalls can be automatically adjusted according to changes in the character's spatial location, effectively avoiding the tedious manual clicking and filtering by the player, and significantly improving the real-time performance and accuracy of information acquisition.

[0069] In one implementation, when a controlled virtual character enters and moves within a specific stall area, the system collects the character's current coordinates in real time according to a preset detection cycle and iterates through the spatial coordinates of all activated stalls within the area, calculating the distance between them. For example, assuming the specific stall area adopts a strict one-stall-one-grid layout, with each grid size being 80 by 80 pixels, when the character moves to the grid in the 3rd row and 4th column, the system determines that the distance parameter between the character and the stall located in the 3rd row and 4th column is zero or close to zero, thus identifying that stall as the nearest target stall and triggering the display of its associated information in a side floating window. Furthermore, if there are non-grid-aligned roaming stalls in the area, the system can calculate the straight-line distance between the character and the geometric center point of the stall, taking the stall corresponding to the minimum value among all calculation results as the target stall. In this process, the system can only respond to candidate stalls that meet the distance threshold condition (e.g., less than 1.5 grid units) to exclude invalid interference from distant stalls.

[0070] Optionally, this distance parameter is used to characterize the spatial distance between the character and the stall, and its specific form can be adaptively set according to the regional layout rules and detection accuracy requirements. Optionally, the calculation rules of the above distance parameter can be adapted to the gridded layout of a specific stall area. In one specific implementation, when the area adopts a strict matrix arrangement of one stall per grid, the distance parameter can be reflected as the comparison result between the grid identifier of the controlled virtual character and the grid identifier of the stall; if the character's coordinates fall within the grid area occupied by a certain stall, the distance parameter between the two can be assigned a zero value or a minimum value, thereby directly establishing that the stall as the object with the closest spatial location. In another implementation, when the distribution of stalls in the area is relatively discrete or allows overlapping across grids, the distance parameter can be defined as the straight-line distance between the character's current coordinates and the origin coordinates or geometric center coordinates of the stall, for example, by calculating the square root of the sum of the squares of the differences between the horizontal and vertical coordinates in a two-dimensional plane coordinate system. Furthermore, considering the potential for obstacles or the tortuous nature of pathfinding paths in game scenarios, this distance parameter can also be set as the actual walking distance accumulated along the walkable path, or as a simplified estimate based on the Manhattan distance. It should be noted that the above explanation of the specific calculation methods for the distance parameter is not intended to exhaust all possibilities. In practical applications, it can be selected or combined according to the computing performance and real-time requirements of the terminal device.

[0071] Optionally, to avoid frequent stall switching interference caused by slight distance differences between distant stalls during densely distributed stalls or rapid character movement, the aforementioned distance-based determination mechanism can also introduce a distance threshold as a pre-filtering condition. This distance threshold can be set to a fixed value, such as 1.5 grid units, only including stalls with a distance parameter less than or equal to this threshold in the candidate set of target stalls; for distant stalls exceeding this threshold range, even if they are near the character, they will be temporarily excluded from the candidate list, thus ensuring the spatial proximity and relevance of the side-view preview content. Furthermore, this distance threshold can be dynamically adjusted based on stall type, product level, or area foot traffic. For example, a larger effective detection radius can be set for stalls selling high-value, rare products, while maintaining a smaller threshold range for ordinary stalls. It should be understood that this threshold parameter can be configured uniformly by developers on the server side, or it can be a user-selectable preference on the client side, allowing players to personalize it according to their browsing habits; this disclosure does not limit this.

[0072] Optionally, the above determination logic may include sorting comparison, threshold filtering, or grid affiliation mapping to filter the most relevant objects from candidate stalls. Optionally, in specific stall areas with strict grid management, the above distance determination can be transformed into an affiliation mapping process based on grid coordinates. Considering the ease of operation and consistency of experience when players browse stalls, the system can directly map the grid cell where the controlled virtual character is currently located to the affiliation identifier of a preset stall within that grid, thereby identifying that stall as the target stall associated with the current location; when the character moves by using the joystick to move or clicks the ground to move into an adjacent new grid, the system immediately switches the target stall to the stall corresponding to the new grid, realizing a step-by-step update of the preview content. In another scenario, if there are multiple micro stalls within the same grid or the character is in the boundary buffer area between two grids, the system can traverse all stalls within the nine-square grid area around the character, calculate the corresponding distance parameters for each, and select the one with the smallest value as the current target stall. If two or more stalls have the same distance parameter or the difference is within the preset tolerance range, the system can randomly select one to display, or it can assist in sorting based on the stall's listing time, credit score, or product richness to determine the final display priority.

[0073] Optionally, considering that multiple stalls of interest to players may exist simultaneously within the same distance range in a real game scenario, at least one target stall is not limited to a single object. Instead, a target set containing multiple candidate stalls can be established based on the distance sorting result. Specifically, the system can arrange all stalls in the area in ascending order of distance parameter, and take the top N stalls as the target stall group, where N is a preset display upper limit value. For example, if N equals 3, it means that the association information of the three closest stalls will be displayed in the side floating window at the same time. At the same time, the graphical user interface can also distinguish the primary target stall from the candidate target stalls through different visual indicators. For example, the highlight border of the closest stall is set to red, and the indicator of the second closest stall is set to an orange dashed border. If the controlled virtual character exceeds the effective distance threshold of a stall during movement, the stall is automatically removed from the target set, and its association information is hidden from the side floating window. The candidate stalls ranked after it are then added to the display queue. This not only ensures that players always have access to the dynamics of the most relevant stalls in their vicinity, but also provides players with a wide range of options for horizontal price comparison when the density of stalls in an area is high.

[0074] In an optional implementation, at least one target functional location is determined based on the distance between the controlled virtual object and each functional location within a specific functional area. This includes identifying stalls located less than a preset distance threshold from the controlled virtual character as target stalls. By using the preset distance threshold for spatial filtering of stalls, interference from distant stall information can be avoided, improving the accuracy of preview information and enhancing scene immersion. In one implementation, when the controlled virtual character enters a specific stall area, the system calculates the spatial interval between the character's location and surrounding stalls. If the distance between a stall and the character's current location is less than a preset distance threshold (e.g., 1.5 grid units), the stall is identified as a target stall, and its associated information is immediately displayed in the graphical user interface. Conversely, if the distance is greater than or equal to the threshold, the stall is not identified as a target stall, and its associated information is not pushed to the side of the interface, thus avoiding interface redundancy and visual interference caused by simultaneously displaying too much distant stall information.

[0075] Optionally, the preset distance threshold is used to limit the effective distance of target stalls around the character, filtering out distant stalls that are outside the range. Optionally, the preset distance threshold can be comprehensively set based on the grid density within a specific stall area, the average spacing between stalls, and the display capacity of the graphical user interface. For example, if the stalls strictly follow the rule of one stall per grid, the preset distance threshold can be set to 1.5 grid units. This means that only when a stall is located within the adjacent or second nearest neighbor grid of the grid currently occupied by the controlled virtual character will it be identified as a target stall and trigger the display of associated information. It should be noted that the specific value of the threshold is not limited to this. In another implementation, if the size of a single grid is large or the information density of the floating window on the side of the interface allows for a higher capacity, the preset distance threshold can also be adjusted to 2 grid units or even larger to cover a wider range of neighboring stalls; conversely, if the interface space is relatively cramped or the goal is to achieve a minimalist information presentation, the preset distance threshold can also be reduced to 1 grid unit, only including the stalls in the current grid occupied by the character and the directly adjacent grids within the target range.

[0076] Optionally, besides using grid units as the metric for the preset distance threshold, the aforementioned distance can also be quantified using pixel distance, absolute length units in the world coordinate system, or relative distance based on screen ratio. In practical applications, the system can obtain the current world coordinates of the controlled virtual character and the coordinate anchor points of each stall in real time. By calculating the straight-line distance or the sum of the horizontal and vertical offsets between two points, and comparing the calculation results with the preset distance threshold, the target stall can be determined. Considering that the player's position is strictly aligned to the grid center in the joystick-attached movement mode, using a threshold based on grid units can significantly reduce the real-time computation load of the server or client. In the point-to-ground movement mode, since the character's position may be in the transition area between grids, using pixel-level or absolute coordinate-level thresholds can provide smoother and more continuous distance judgment boundaries, avoiding judgment jumps caused by unit rounding at grid boundaries.

[0077] Optionally, the aforementioned preset distance threshold does not necessarily have to be a fixed constant. It can be dynamically adjusted based on the movement status of the controlled virtual character, the crowding level of the current stall area, or the player's historical interaction habits. For example, when the controlled virtual character is detected to be moving quickly, in order to prevent visual interference caused by frequent refreshes of the interface's related information of distant stalls, the system can temporarily reduce the preset distance threshold, so that only stalls at very close range are identified as target stalls. When the character is stationary or browsing slowly, the system can appropriately increase the preset distance threshold, making it easier for the player to know the general information of the goods in stalls slightly further away in advance. In addition, if there are multiple stalls that meet the distance conditions in a specific stall area, the system can further sort them by combining the stall's azimuth, orientation, or product popularity, prioritizing the display of related information of the stalls located directly in front of or to the side of the controlled virtual character and closest to them. This further improves the rationality of target stall selection and the player's smooth browsing experience based on the distance dimension.

[0078] In an optional implementation, the associated information includes at least one of the following: virtual product name information, virtual product price information, virtual product icon information, and virtual product inventory status. This allows players to directly obtain core transaction parameters without opening the stall details, significantly shortening the information acquisition path and improving browsing efficiency and transaction decision-making speed.

[0079] In one implementation, the controlled virtual character triggers an adsorption displacement by sliding the joystick upwards, moving from the current grid coordinates to the grid containing the target stall above. At this time, the system automatically generates a preview pop-up window in the right sidebar of the graphical user interface, listing the stall's associated information from top to bottom: the first line displays the virtual item name "Healing Potion," followed immediately by the price value "50 Gold Coins" highlighted in green; to the left of the name is a product thumbnail icon of 80×80 pixels; below the price value is the inventory status label "3 remaining / 10 total." As the player character continues to move towards adjacent stalls, the pop-up window dynamically refreshes with the changing position, allowing the player to determine in real-time whether to stop and trade based on the aforementioned multi-dimensional information without needing to click on any stall model or pop up a secondary interface.

[0080] Optionally, virtual product name information is used to identify the name text of the items for sale in the preview pop-up window, helping players quickly identify the products.

[0081] Optionally, the virtual product name information can be a text string, compound text with a grade prefix, or a rich text label with color differentiation; its specific presentation is not limited in this disclosure. In the side pop-up window of the graphical user interface, this name information is usually arranged as a single line of text at the top or far left of the product entry, allowing players to read it directly without triggering any pop-ups or expansion actions. In addition to the full official name, the name information can also include a brief description or category suffix, such as adding "Consumable" after the name for potion products, and adding a part restriction description for equipment products. It should be noted that the above-mentioned presentation of name information is only an example. In actual implementation, it can be dynamically adjusted according to the game category or specific interaction requirements. For example, in high-density stall areas, only the abbreviation can be displayed to compress the pop-up window height, while the full name can be restored in detailed browsing mode.

[0082] Optionally, virtual goods price information is used to display the virtual transaction price of the items for sale in the preview pop-up window to assist players in making purchasing decisions.

[0083] Optionally, the price information for virtual goods may include not only the base price but also bundled discounts, unit price comparison labels, or fluctuating price ranges based on market conditions; this disclosure does not impose any limitations on this. Considering that players need to quickly make price comparison decisions while browsing on mobile devices, this price information is typically displayed directly in a high-contrast numeric font adjacent to the product name, and can be differentiated by color coding; for example, products below the market average price are highlighted in green, while premium products are presented in regular white or gray. Furthermore, this price information can be correlated with the amount of virtual currency held by the player, generating a shortage warning mark next to the price when the balance is insufficient. In this way, players do not need to click to open each transaction details page individually; they can grasp the price levels of goods at each stall in real time during the browsing process, effectively reducing invalid interactions caused by information asymmetry.

[0084] Optionally, virtual product icon information is used to display the graphic identifier of the items for sale in the preview pop-up window, assisting players in identifying products through visual features. Optionally, the virtual product icon information can be a static 2D image, a dynamic thumbnail with special effects, or a rotatable 3D model preview image. Its arrangement and size can be dynamically adapted according to the current unfolded state of the pop-up window. In the side preview pop-up window of the graphical user interface, this icon information is usually displayed on the far left of the product item, serving as the primary anchor point for the player's visual scanning. Its display area can be set to no less than a preset pixel threshold (e.g., 80×80 pixels) to ensure sufficient recognizability on small-screen devices. In addition to directly displaying standard icons, for equipment items with durability or enhancement levels, this icon information can also be overlaid with status badges or progress bars, such as displaying a red crack mark in the lower right corner of an unrepaired equipment icon. If network latency causes the icon resource to not be fully loaded, a placeholder background image can be displayed first, and then smoothly replaced after the data packet is received. This disclosure does not limit the specific loading strategy.

[0085] Optionally, the virtual goods inventory status is used to indicate the tradable quantity or sold-out status of the items in the preview pop-up window, avoiding unnecessary player interaction. Optionally, the virtual goods inventory status can be represented as a remaining quantity value, a progress bar for the number of tradable items, or a binary status label for sold-out / restocked; its specific presentation is not limited in this disclosure. To prevent players from being forced to perform unnecessary interaction after selecting a stall only to find that the goods are sold out, this inventory status is usually placed next to the price information and distinguished by eye-catching color changes. For example, a regular white number is displayed when the stock is sufficient, an orange warning font is switched when the stock is low, and the entire item is grayed out and overlaid with the text "Sold Out" when it is completely sold out. In addition to the precise remaining quantity, for tradable items stacked in batches, the inventory status can also automatically switch to semantic labels such as "Abundant," "Short," or "Urgent" based on the current remaining quantity as a percentage of the total stack limit, thereby reducing the reading burden of numerical density when the pop-up window space is limited. In this way, players can judge the tradability potential of each stall in real time while moving through the grid, and prioritize stalls with sufficient inventory to stay at, effectively improving the overall efficiency of browsing and trading stalls.

[0086] In step S250, the associated information is displayed in the graphical user interface. This approach, by directly embedding the stall's associated information into the graphical user interface for visualization, avoids the fragmented experience caused by repeatedly opening product detail windows. It synchronizes product browsing with player movement, significantly reducing the frequency of interface transitions and enhancing the immersive and seamless experience of browsing the stalls.

[0087] In one example, when the controlled virtual character moves to a target stall within a specific stall area and stays there, a semi-transparent floating window, approximately one-fifth the width of the screen display area, smoothly pops up on the right edge of the graphical user interface. This floating window displays the virtual goods for sale at the target stall in a vertical list. Each item displays a 64-pixel by 64-pixel icon on the left and, from top to bottom, the virtual goods name, unit price, and inventory status on the right. Furthermore, if the player continues to move to an adjacent stall, the side floating window will complete a fade-in and fade-out transition animation within 0.3 seconds, dynamically refreshing with the new stall's associated information, while the main scene view continues to move continuously, requiring no manual closing or reopening of the window by the player.

[0088] Figure 4 A schematic diagram of the interface of a virtual booth interaction method in one exemplary embodiment of this disclosure is shown. Optionally, an information display area generated in the graphical user interface is used to present the virtual product data of the target stall in the form of a visual list. Optionally, the display area of ​​the aforementioned related information in the graphical user interface can be set in different positions such as the left edge, right edge, or above the bottom toolbar of the screen. Its presentation form can be a semi-transparent floating window, a collapsible sidebar, or a fixed panel embedded in the edge of the scene. It should be noted that this display area is usually visually suspended above the main scene rendering layer, but its display area generally does not exceed one-quarter of the screen display area to avoid excessively obscuring the game scene. Considering that players need to continuously observe the distribution of stalls and the location of the controlled virtual character while browsing stalls, placing the information display area at the edge of the screen allows players to browse the product data of the target stall in real time without interrupting their movement; on the other hand, it effectively preserves the main field of view in the center of the scene, significantly reducing the distraction and spatial perception disruption caused by the forced interruption of the full-screen pop-up interface.

[0089] Optionally, the related information presented in the aforementioned display area may include, but is not limited to, virtual product name information, virtual product price information, virtual product icon information, and virtual product inventory status. Its actual arrangement can be a single-column vertical list, a double-column card grid, or a horizontal scrolling bar. It should be noted that the display priority of the above information can be dynamically adjusted according to the actual composition of the stall data: for example, when a virtual product has a scarcity attribute or a limited-time discount, its price information can be highlighted in a bright color or enlarged font; when the inventory quantity of a product is lower than a preset warning value, a remaining quantity badge or out-of-stock label can be superimposed on the upper right corner of the product icon. The purpose of this display method is to present the key operating data of the stall in a structured and hierarchical form directly at the edge of the scene, allowing players to quickly compare and filter the value of multiple stall products while moving without having to perform additional operations such as entering submenus or opening details pages.

[0090] Optionally, when the controlled virtual character changes position within a specific stall area, the associated information within the aforementioned display area can be updated synchronously. As mentioned earlier, during the process of a player switching from a target stall to an adjacent stall using displacement operations in interactive control mode, the system can determine the new nearest stall based on the real-time distance detection relationship between the controlled virtual character and each stall, and automatically replace the product name, price, icon, and inventory status in the display area with the corresponding data of the new stall. Furthermore, to avoid visual interference and wasted computing resources caused by frequent refreshes of display content during high-speed character movement, if the controlled virtual character's movement speed exceeds a preset speed threshold, the display area can be temporarily hidden or its content updates frozen; until the character's movement speed falls below the threshold and stabilizes at a certain grid stall, distance detection is retried and the corresponding associated information is loaded. It should be understood that the above dynamic refresh mechanism is not only applicable to continuous adsorption movement scenarios, but also to the instantaneous preview needs of players when they briefly pass by a stall through free movement, thus taking into account the information acquisition experience in both detailed browsing and fast map traversal states.

[0091] In an optional implementation, the method further includes displaying visual cues for at least one target stall in a graphical user interface. By configuring visual cues for corresponding stalls and rendering them on the scene interface, players' attention can be anchored to the target stalls in the space, reducing confusion in densely packed displays and improving the accuracy of stall location and browsing.

[0092] In one implementation, when the controlled virtual character stops at the grid coordinates of the target stall within a specific stall area, a high-contrast visual indicator is generated directly above the stall in the graphical user interface, such as... Figure 4 As shown, for example, a semi-transparent arrow pointing vertically downwards updates its position in real time as the stall's spatial coordinates change. It automatically migrates to the new target stall as the player continuously moves towards adjacent stalls, thus ensuring the player maintains a constant awareness of the stall's spatial location without disrupting the scene's continuity. Optionally, visual indicators are used to mark target stalls within the scene; their presentation can include arrows, halos, or glowing outlines.

[0093] Optionally, the aforementioned visual indicators can be semi-transparent arrows floating above the target stall, glowing borders surrounding the stall's outline, or beams of particle light emanating upwards from the stall model. Their color parameters can be differentiated based on the stall's status; for example, ordinary stalls can be identified with a light blue halo, while stalls selling rare virtual goods can be identified with a shimmering gold effect. These visual indicators can be directly and permanently displayed in the scene layer, or they can be dynamically generated after a controlled virtual character enters a specific stall area and triggers the interactive control mode. Considering that players may experience spatial confusion when multiple stalls are densely arranged within a stall area, these visual indicators can quickly focus the player's attention on the stall entity corresponding to the associated information displayed in the side floating window, thus avoiding repeated searching among numerous similar models and establishing an intuitive mapping relationship between the side floating window and the scene space.

[0094] Optionally, if only one entity is identified as a target stall, the graphical user interface will only display a visual indicator at that stall. If multiple target stalls simultaneously meet the distance threshold condition, different levels of visual indicators can be displayed simultaneously or sequentially on each target stall. For example, the closest first stall can be displayed as a highlighted arrow, and the second closest stall as a dashed outline. As mentioned earlier, during the suction-type displacement process, when the controlled virtual character moves from the current grid coordinates to an adjacent stall, the visual indicator can produce a smooth transition animation along with the displacement process. For example, the visual indicator of the original target stall fades out within 0.3 seconds, and the visual indicator of the new target stall gradually appears within the same time, thus achieving a seamless switching of visual focus. Furthermore, if the movement speed of the controlled virtual character exceeds a preset speed threshold, causing the associated information floating window to be closed, the visual indicator can also be hidden simultaneously to avoid redundant visual interference during rapid map movement.

[0095] In an optional implementation, the method further includes controlling the display status of related information based on the movement speed of the controlled virtual character. This allows for dynamic adjustment of information display by sensing the character's movement speed, automatically closing the preview window during high-speed movement, effectively preventing interface elements from interfering with combat or map exploration scenarios, and ensuring the continuity and smoothness of game operations.

[0096] In one implementation, when a player controls a virtual character to move between stall grids at a low speed using a joystick, the system continuously monitors its movement speed and determines that it does not exceed a preset speed threshold; the associated information floating window on the side of the graphical user interface remains displayed. However, when the player switches to a point-and-click navigation mode to quickly traverse a specific stall area, the movement speed of the controlled virtual character rapidly increases to above the aforementioned threshold. The system immediately triggers an anti-interference mechanism, automatically canceling the display of the side floating window until the movement speed decreases or the player re-enters a more detailed browsing state. Optionally, the aforementioned movement speed refers to the rate of movement of the controlled virtual character within the stall area, used by the system to determine whether to maintain the dynamic display of associated information.

[0097] Optionally, the aforementioned movement speed can be represented as the inherent grid switching rate in the joystick-attach movement mode, or as the character's running or walking speed in the point-and-click pathfinding mode. When the player makes eight-directional inputs using the joystick, the controlled virtual character switches between adjacent stall grids at a preset attachment speed. This speed is usually configured to be below a preset speed threshold, allowing the system to continuously perform real-time distance detection and refresh the side-mounted related information floating window during movement. Considering that players need sufficient time to read core information such as product names and prices when browsing in densely populated stall areas, limiting the joystick-attach movement speed to a low range can effectively ensure the integrity and accuracy of information reading. Furthermore, the specific value of this movement speed is not fixed; it can be dynamically adjusted according to the size of the stall grid, the density of product information, or the player's personal preferences. For example, the attachment movement time per grid can be set to 0.5 seconds or 0.8 seconds to balance browsing efficiency and information acquisition comfort.

[0098] Optionally, to avoid frequent flickering of the related information floating window due to brief speed fluctuations or network latency, the above-mentioned movement speed determination logic does not rely on instantaneous frame rate calculation, but uses the average rate within the sliding time window as the decision basis. Specifically, the system can collect displacement samples of the controlled virtual character in the past 0.5 seconds or 1 second, calculate its average movement speed, and compare the average speed with a preset speed threshold. If the average speed exceeds the threshold, it is determined that the player is currently intending to pass quickly, thereby triggering the instruction to hide the side floating window; if the average speed is below the threshold, the floating window is maintained. In addition to the judgment mechanism based on average speed, a composite judgment can also be made by combining acceleration trends or the frequency of changes in displacement direction. For example, when the controlled virtual character continuously moves at high speed in one direction for more than 2 grid units, even if there are fluctuations in instantaneous speed, the system can still switch the display state to hidden. This disclosure does not limit this.

[0099] Optionally, the timing of the aforementioned movement speed detection is tightly coupled to the entry status of a specific stall area. It is not continuously collected across the entire map, but rather the speed monitoring thread is only activated after the interactive control mode is triggered. This design has two advantages: firstly, it reduces the CPU overhead in non-stall areas, avoiding unnecessary background calculations; secondly, it prevents the system from mistakenly applying the stall browsing-specific speed threshold logic to the global scene when players are engaged in high-speed combat or traveling in open areas, thus avoiding abnormal pop-ups or hiding of related information windows. In actual deployment, this speed monitoring thread can collect the world coordinate displacement difference of the controlled virtual character at a frequency of one frame or every 0.1 seconds using a timer, and calculate the instantaneous or average rate using the time step provided by the game engine. If the player exits a specific stall area, the monitoring thread is automatically destroyed or suspended until it is reinitialized upon the next entry.

[0100] Optionally, the aforementioned display state includes one or more of showing, hiding, or partially transparent display, which dynamically switches according to the real-time movement speed of the controlled virtual character. Optionally, the aforementioned display state can be directly controlled through the visibility parameters of the side floating window in the graphical user interface. When the movement speed of the controlled virtual character does not exceed a preset speed threshold, the display state is configured to be fully displayed, at which time the side floating window fully presents the target stall's product name, price, icon, and other related information in an opaque or highlighted form. When the movement speed exceeds the preset speed threshold, the display state is switched to hidden, and the side floating window is removed from the interface or shrunk to a very small indicator dot to avoid obstructing the scene's view during combat or map exploration. To avoid abrupt transitions during the display state switching process, the aforementioned hiding or showing actions can also be accompanied by a gradual fade-in / fade-out transition animation, where the transition duration can be set to 0.2 seconds or 0.3 seconds, thus providing the player with a smooth visual feedback rather than abrupt interface flickering. It should be noted that the switching of the above display states is not limited to binary display and hiding, but may also include a semi-transparent preview state or a simplified state that only retains the text summary. This disclosure is not intended to limit the specific level of the display states.

[0101] Optionally, to further reduce the sense of disorientation caused by the sudden disappearance of stall information during high-speed movement, the system can briefly retain a directional visual identifier in the graphical user interface before switching the display state to hidden. This identifier could be an arrow icon approximately 20 pixels high and 10 pixels wide, continuously indicating the location of the nearest target stall. The display state of this visual identifier can be controlled independently of the side floating window. Even after being hidden, it can remain displayed for 1 to 2 seconds, or be restored to a full floating window when the movement speed drops below a threshold. If the controlled virtual character repeatedly oscillates around the threshold boundary, causing frequent switching of the display state, the system can introduce a hysteresis interval mechanism. For example, by setting an upper and lower floating threshold, the floating window is closed only when the movement speed is higher than the upper floating threshold, and reopened when the movement speed is lower than the lower floating threshold, thereby effectively suppressing interface jitter caused by speed spikes. It should be understood that the specific values ​​of the aforementioned lag range can be configured individually according to the combat or browsing needs of different scenarios. For example, the lag range can be appropriately widened in the main city's commercial area, while the judgment conditions can be tightened in high-incidence combat areas such as dungeon entrances.

[0102] In an optional implementation, the display status of related information is controlled based on the movement speed of the controlled virtual character, including: canceling the display of related information in the graphical user interface when the movement speed exceeds a preset speed threshold. This automatically disables the display of related information when the player moves quickly through the stall area, avoiding visual interference caused by frequent refreshes of the side floating window and ensuring smoothness and immersion in map exploration or combat scenarios. In one implementation, the interactive system continuously monitors the movement speed of the controlled virtual character as it moves within a specific stall area. If the player uses location navigation or continuously drags the joystick to make the controlled virtual character quickly traverse multiple stalls, and the system determines that its movement speed exceeds a preset speed threshold, the related information floating window displayed in the side area of ​​the graphical user interface is immediately canceled, preventing visual interference from stall product information during rapid movement. When the controlled virtual character decelerates below the threshold and stops at the grid position corresponding to a target stall, the floating window reappears and displays the stall's product name, price, icon, and other related information.

[0103] Optionally, this preset speed threshold is used to define the boundary between browsing and passage states, and can be configured according to differences in stall density or displacement patterns.

[0104] Optionally, the aforementioned preset speed threshold can be a fixed value or a variable parameter that is dynamically adjusted based on the current displacement mode of the controlled virtual character. Considering the objective differences in the movement characteristics of the controlled virtual character under different operation modes, when the player controls the controlled virtual character to move through the grid using a joystick, its running speed is usually low and stable, suitable for browsing between adjacent stalls one by one; while when the player uses the point-and-click pathfinding or free-running mode, the movement speed of the controlled virtual character is usually significantly higher, with the aim of quickly traversing the stall area rather than stopping to view. Based on this, to avoid visual interference caused by the high-frequency switching of the side-mounted related information floating window during rapid movement, the system can set the preset speed threshold to an intermediate value between the fine browsing speed and the free-running speed. For example, when the movement speed of the controlled virtual character reaches one to two grid units per second, it is judged as a high-speed state, thereby triggering the cancellation of the display of related information. Furthermore, this threshold can also be dynamically adjusted according to the actual arrangement density of stalls in a specific stall area. If the current area has a sparse distribution of stalls, the threshold can be appropriately increased, and vice versa, thereby achieving a dynamic balance between ensuring the browsing experience and reducing interface interference. It should be noted that the above description of the velocity dimension and the number of grid units is only an illustrative example. In actual implementation, other velocity measurement methods such as pixels per second or in-game logical distance per second may also be used. This disclosure is not intended to limit this.

[0105] Optionally, the process of setting the aforementioned preset speed threshold can also incorporate adaptive learning using historical movement data of the controlled virtual character. For example, the system can statistically analyze the distribution of a player's normal movement speed within a specific booth area, setting the threshold to the upper quartile or a certain percentile of this distribution. This ensures that most normal, rapid passage will trigger the cancellation of related information display, while occasional momentary acceleration will not cause the floating window to close. Furthermore, to avoid the impact of detection latency caused by differences in terminal device performance on accuracy, the aforementioned speed detection can use a smoothing filtering algorithm to calculate position data from multiple consecutive frames, obtaining a more stable estimate of instantaneous speed, which is then compared with the preset speed threshold. It should be noted that the aforementioned adaptive adjustment mechanism and filtering method are merely extended examples. In actual implementation, fixed empirical values ​​or manual configuration by the administrator can also be used. This disclosure does not aim to limit the specific method of determining the threshold.

[0106] Optionally, this cancellation operation aims to disable the output of side-related information during high-speed displacement, reducing visual interference caused by frequent interface refreshes.

[0107] Optionally, the timing of canceling the display of associated information in the graphical user interface depends not only on the instantaneous speed determination but also on a comprehensive decision based on the duration or displacement acceleration. In practical applications, the controlled virtual character may experience instantaneous speed fluctuations due to brief shifts in joystick direction or rebound effects from collisions. If the speed peak detected in a single frame is used as the sole criterion for canceling the display, the side floating window may repeatedly appear and disappear within a very short time, thus weakening the stability of the interactive experience. To avoid this judgment jitter, the system can cancel the display of associated information only after detecting that the movement speed of the controlled virtual character has continuously exceeded a preset speed threshold for a specified duration. Similarly, when the movement speed of the controlled virtual character falls below the threshold, or when the player stops inputting displacement commands and remains on the current grid for a preset pause time, the system can reload and display the associated information of the corresponding target stall in the side area of ​​the graphical user interface. It should be noted that the conditions for restoring the display can be exactly the same as those for canceling the display, or an asymmetric delay strategy can be adopted depending on the different interaction focuses. For example, a lower trigger threshold can be set than for canceling the display, so that the floating window returns to the display state more quickly after the player slows down.

[0108] In an optional implementation, the related information is displayed in the graphical user interface, including displaying the related information as a floating window in the side area of ​​the graphical user interface. This allows players to dynamically display stall-related information via a side floating window, enabling them to browse products simultaneously without interrupting their movement. This avoids the disruption to the immersive experience caused by interface transitions, effectively improving the efficiency and continuity of browsing.

[0109] In one example, when the controlled virtual character moves to the grid coordinates corresponding to the target stall, a vertical semi-transparent floating panel is generated on the right edge of the graphical user interface. The floating window displays the virtual product icons, names, and price information of the stall in a list format. The player can continue to push the joystick to control the character's movement. The floating window automatically refreshes its content after the character enters the new grid coordinates. The entire browsing process does not require opening or closing any full-screen interface.

[0110] Optionally, the floating window in this side area is used to continuously display related information during movement, avoiding interruptions to the immersive experience and operational continuity caused by full-screen interface transitions.

[0111] Optionally, the aforementioned side area can be the left or right edge of the graphical user interface. The floating window can be presented as a draggable semi-transparent floating panel, an edge-attached information bar, or a foldable drawer window. Considering that players need to pay attention to both character movement and product information while browsing stalls, the display width of the floating window can be controlled between 20% and 35% of the screen width, and the vertical height can adaptively extend according to the number of products to avoid obscuring too much of the game scene. The floating window can contain information such as the icon, name, price, and inventory status of the virtual products sold at the current target stall. This information is arranged in a list from top to bottom, and separators or white space can be set between each product item to improve readability. It should be noted that the above description of the specific size, position, and visual style of the floating window is only one example, and this disclosure is not intended to limit it. In actual implementation, it can be adaptively adjusted according to the screen resolution of the terminal device, the landscape or portrait display mode, and the player's personalized settings.

[0112] Optionally, to avoid visual fatigue caused by excessively frequent updates to the floating window information, the above method can first display a preview bar of the new stall's associated information in the side area when the controlled virtual character is detected entering a new grid coordinate. After the character remains in the grid corresponding to that stall for more than a preset time (e.g., any value between 0.5 seconds and 2 seconds), the floating window content can then be fully expanded. Furthermore, when the controlled virtual character's movement speed exceeds a preset speed threshold, the side floating window can automatically collapse to display only a badge or thumbnail indicating the number of stalls, and then restore the full information display once the speed falls below the threshold. In other words, there is a dynamic mapping relationship between the floating window's display state and the controlled virtual character's movement behavior. This mapping relationship considers not only the player's browsing needs but also the rendering performance of the terminal device. In addition, the floating window can respond to player gestures, such as swiping outwards to close the floating window or swiping inwards to expand detailed information. This ensures information accessibility while giving players the ability to control the intensity of information display, improving the flexibility of interaction.

[0113] In an optional implementation, the method further includes: dynamically updating the associated information displayed in the graphical user interface in response to changes in the position of the controlled virtual object within a specific booth area. This dynamic adjustment of the displayed information through a real-time location awareness mechanism allows players to obtain accurate location information as they move between different areas within the booth, avoiding lag and inaccuracy in information display and effectively improving the refined experience of booth browsing and information acquisition efficiency.

[0114] In one example, when the controlled virtual character moves from the product display area to the price tag area within a booth, the content of the floating window on the right side of the graphical user interface changes in real time from displaying the product's appearance image and basic introduction to the product's detailed price information, promotional activities, and inventory status. When the character moves further to the trial experience area, the floating window content is updated again to the product's operation guide, user reviews, and related accessory recommendations. The entire information update process is completed within 0.2 seconds after the character's position changes, ensuring a high degree of synchronization between information display and character movement.

[0115] Optionally, this dynamic update mechanism is based on a fine-grained grid coordinate system within the booth, where each grid cell corresponds to a specific type of associated information. An information update event is triggered when the controlled virtual object crosses the grid boundary.

[0116] Optionally, the aforementioned specific booth area can be divided into multiple functional sub-areas, including but not limited to: a product display area, a price information area, a user review area, a related recommendations area, and a purchase operation area. Each sub-area corresponds to different dimensions of related information. For example, the product display area mainly displays high-definition images, 3D model previews, and basic parameters of the products; the price information area focuses on displaying product prices, discount information, member benefits, and installment payment options; the user review area mainly displays purchase reviews, rating statistics, and user experiences from other players; the related recommendations area displays comparisons of similar products, matching suggestions, and best-selling rankings; and the purchase operation area provides interactive buttons such as "Buy Now," "Add to Cart," and "Favorite Product." When the controlled virtual character moves between these sub-areas, the related information in the graphical user interface will be adjusted accordingly based on the functional attributes of the current area to ensure the relevance and usability of the information display. The boundaries of each sub-region can be defined by coordinate ranges. For example, the coordinate range of the product display area is (x1, y1) to (x2, y2), and the coordinate range of the price information area is (x2, y1) to (x3, y2). The system determines the specific location of the virtual character by comparing its current coordinates with the coordinate ranges of each sub-region in real time. It should be noted that the above description of sub-region division and information types is only one example, and this disclosure is not intended to limit it. In actual implementation, it can be flexibly configured according to different product types, stall sizes, and merchant needs.

[0117] Optionally, to ensure smooth dynamic updates and user experience, the above method employs a gradual information transition strategy when detecting a change in the controlled virtual character's position. This involves first performing a fade-out animation on the currently displayed related information (lasting 0.1 to 0.3 seconds), then loading the information content corresponding to the new position, and finally performing a fade-in animation to display the new information. Furthermore, to avoid frequent positional adjustments causing overly sensitive information updates, the system can set a positional change threshold. Information updates are only triggered when the virtual character's displacement exceeds a preset threshold (e.g., from 0.5 grid units to 1 grid unit). Simultaneously, the system can set an update frequency limit to ensure that the information update interval is no less than a preset time (e.g., 0.3 to 1 second) to prevent excessively frequent updates from affecting the visual experience. In addition, this dynamic update mechanism also supports information preloading. When a virtual character approaches the boundary of a sub-region, the related information for that region is preloaded in the background. When the character officially enters the region, it can be displayed immediately, eliminating the waiting time for information loading and improving response speed. In addition, when a controlled virtual character stays in the same sub-area for more than a preset time (e.g., three to ten seconds), the system can proactively push in-depth information or relevant suggestions for that area. For example, when staying in the product display area, it can push detailed specifications comparisons of the products, and when staying in the price information area, it can push reminders of limited-time offers, thereby achieving proactive and intelligent information display.

[0118] According to one embodiment of the virtual booth interaction device 300 of this disclosure, a graphical user interface is provided through a terminal device. The graphical user interface displays at least a portion of the game scene, and the game scene includes a controlled virtual character controlled through the terminal device, such as... Figure 5 As shown, the device 300 may include: The area providing module 301 is used to provide a specific booth area in the graphical user interface of the game scene; The interaction control module 302 is used to activate the interaction control mode for the controlled virtual object when the controlled virtual character enters a specific booth area. The movement control module 303 is used in interactive control mode to control the controlled virtual character to perform a suction-type displacement within a specific stall area in response to a displacement input command acting on the controlled virtual character, so as to move to a target stall. The information determination module 304 is used to determine at least one target stall associated with the location based on the location of the controlled virtual character in a specific stall area, and to obtain the association information of at least one target stall. The information display module 305 is used to display related information in a graphical user interface.

[0119] This reduces the length of the interaction path and the redundancy of terminal operation commands in virtual booth browsing scenarios, which helps to reduce the impact of frequent interface switching on terminal rendering processing overhead, improve the efficiency of obtaining virtual product information, and reduce the computational load during the frequent creation and destruction of interface elements on the terminal side.

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

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

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

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

[0124] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

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

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

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

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

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

Claims

1. A virtual booth interaction method, comprising providing a graphical user interface via a terminal device, the graphical user interface displaying at least a portion of a game scene, the game scene including a controlled virtual character controlled via the terminal device, characterized in that, The method includes: A specific booth area is provided in the graphical user interface of the game scene; When the controlled virtual character enters the specific booth area, an interactive control mode for the controlled virtual object is triggered; In the interactive control mode, in response to a displacement input command applied to the controlled virtual character, the controlled virtual character is controlled to perform an adsorption-like displacement within the specific stall area to move to a target stall; Based on the location of the controlled virtual character within the specific stall area, determine at least one target stall associated with the location, and obtain the association information of the at least one target stall; The associated information is displayed in the graphical user interface.

2. The method according to claim 1, characterized in that, In the interactive control mode, the stalls in the specific stall area are arranged according to a preset grid.

3. The method according to claim 2, characterized in that, The controlled virtual character performs an adsorption-like displacement within the specific booth area, including: The displacement direction indicated by the displacement input command is mapped to the coordinate offset in a preset grid coordinate system centered on the current position of the controlled virtual character; Based on the coordinate offset, the controlled virtual character is controlled to move to the target stall in an adhesive manner.

4. The method according to claim 3, characterized in that, The method further includes: In response to continuously receiving the displacement input command in the same direction, the controlled virtual character is controlled to continuously perform multiple displacements in the preset grid coordinate system, so as to move to multiple adjacent target stalls in sequence.

5. The method according to claim 1, characterized in that, Based on the location of the controlled virtual character within the specific stall area, determining at least one target stall associated with the location includes: The at least one target stall is determined based on the distance between the controlled virtual character and each stall within the specific stall area.

6. The method according to claim 5, characterized in that, Determining the at least one target functional location based on the distance between the controlled virtual object and each functional location within the specific functional area includes: Stalls that are less than a preset distance threshold from the controlled virtual character are identified as the target stalls.

7. The method according to claim 1, characterized in that, The associated information includes at least one of the following: virtual product name information, virtual product price information, virtual product icon information, and virtual product inventory status.

8. The method according to claim 1, characterized in that, The method further includes: The graphical user interface displays visual signage for the at least one target stall.

9. The method according to claim 1, characterized in that, The method further includes: The display status of the associated information is controlled based on the movement speed of the controlled virtual character.

10. The method according to claim 9, characterized in that, The step of controlling the display state of the associated information based on the movement speed of the controlled virtual character includes: If the movement speed exceeds a preset speed threshold, the associated information will be removed from the graphical user interface.

11. The method according to claim 1, characterized in that, Displaying the associated information in the graphical user interface includes displaying the associated information as a floating window in the side area of ​​the graphical user interface.

12. The method according to claim 1, characterized in that, The method further includes: In response to changes in the position of the controlled virtual object within the specific booth area, the associated information displayed in the graphical user interface is dynamically updated.

13. A virtual booth interactive device, providing a graphical user interface via a terminal device, the graphical user interface displaying at least a portion of a game scene, the game scene including a controlled virtual character controlled via the terminal device, characterized in that, The device includes: A region providing module is used to provide a specific booth area in the graphical user interface of the game scene; The interaction control module is used to activate the interaction control mode for the controlled virtual object when the controlled virtual character enters the specific booth area. A movement control module is used in the interactive control mode to control the controlled virtual character to perform an adsorption-type displacement within a specific stall area in response to a displacement input command applied to the controlled virtual character, so as to move to a target stall. The information determination module is used to determine at least one target stall associated with the location of the controlled virtual character within the specific stall area, and to obtain the association information of the at least one target stall. An information display module is used to display the associated information in the graphical user interface.

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

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, are used to implement the booth scene interaction method as described in any one of claims 1 to 12.

Images