Virtual throwing interaction method and device, electronic device, and storage medium

Abstract

An embodiment of the present disclosure provides an interactive method of virtual throwing, comprising: providing a first throwing operation control in a graphical user interface, the first throwing operation control being configured with a first sub-area and a second sub-area, wherein the first sub-area is used to trigger a high-throw throwing, and the second sub-area is used to trigger a low-throw throwing; detecting a spatial positional relationship between a virtual character and a virtual obstacle in a game scene; when the spatial positional relationship meets a preset condition, providing a second throwing operation control in the graphical user interface, the second throwing operation control being configured with the first sub-area, the second sub-area, and at least one third sub-area, the third sub-area being used to trigger a side-throw throwing; and determining a throwing trajectory of a virtual prop in response to a sliding operation on the first throwing operation control or the second throwing operation control.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to interactive methods, apparatuses, electronic devices, and storage media for virtual throwing. Background Technology

[0002] In relevant game interaction scenarios, virtual throwing props are often used to interact with the environment. In related technologies, players typically trigger the release of virtual props through operation controls in a graphical user interface. When it is necessary to change the throwing direction, existing interaction solutions usually rely on the physical rebound of the virtual prop after colliding with scene obstacles to change its trajectory and achieve a lateral throwing effect.

[0003] However, the above-mentioned solutions are limited by the distribution of virtual obstacles, making it difficult to achieve lateral throwing in the absence of effective rebound conditions, thus restricting the interaction methods. In addition, the above-mentioned solutions require frequent reliance on physical rebound mechanisms to adjust direction, which forces the terminal to perform a large number of collision detection and trajectory simulation calculations, increasing the processor's computational load. At the same time, the additional independent operation controls configured to achieve multi-directional throwing also increase the rendering overhead of the graphical user interface, and the interaction efficiency and resource utilization need to be improved. Summary of the Invention

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

[0005] According to one aspect of this disclosure, a virtual throwing 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 at least one virtual character. The method includes: providing a first throwing operation control in the GUI, the first throwing operation control being configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw and the second partition is used to trigger a low-throw throw; detecting the spatial positional relationship between the virtual character and virtual obstacles in the game scene; when the spatial positional relationship meets preset conditions, providing a second throwing operation control in the GUI, the second throwing operation control being configured with a first partition, a second partition, and at least one third partition, the third partition being used to trigger a lateral throw; and determining the throwing trajectory of a virtual prop in response to a sliding operation applied to the first or second throwing operation control.

[0006] According to one aspect of this disclosure, a virtual throwing interactive device is provided, which provides a graphical user interface through a terminal device. The graphical user interface displays at least a portion of the game scene, and the game scene includes at least one virtual character. The device includes: a first providing module for providing a first throwing operation control in the graphical user interface. The first throwing operation control is configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw and the second partition is used to trigger a low-throw throw. The detection module is used to detect the spatial relationship between virtual characters and virtual obstacles in the game scene; The second providing module is used to provide a second throwing operation control in the graphical user interface when the spatial position relationship meets the preset conditions. The second throwing operation control is configured with a first partition, a second partition and at least one third partition, and the third partition is used to trigger a lateral throw. The throwing module is used to determine the throwing trajectory of virtual props in response to a sliding operation on the first or second throwing operation control.

[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 executing the computer program instructions implements an interactive method for any of the above virtual throwing 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 interactive methods for virtual throwing.

[0009] One embodiment of this disclosure provides an interactive method for virtual throwing, comprising: providing a first throwing operation control in a graphical user interface, the first throwing operation control being configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw and the second partition is used to trigger a low-throw throw; detecting the spatial positional relationship between a virtual character and virtual obstacles in a game scene; when the spatial positional relationship meets a preset condition, providing a second throwing operation control in the graphical user interface, the second throwing operation control being configured with a first partition, a second partition, and at least one third partition, the third partition being used to trigger a lateral throw; and determining the throwing trajectory of a virtual prop in response to a sliding operation applied to the first or second throwing operation control. In this way, by dynamically switching control partitions and determining the throwing trajectory in response to sliding operations, the interaction path for lateral throwing is simplified, which helps to reduce the computational load on the terminal during physical bounce detection and trajectory simulation, and reduces additional interface control rendering overhead, thereby improving interaction efficiency and resource utilization. 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; Figure 2 A flowchart illustrating an interactive method for virtual throwing in one exemplary embodiment of this disclosure is shown. Figure 3 A schematic diagram of the interface for an interactive method of virtual throwing in one exemplary embodiment of this disclosure is shown. Figure 4 A schematic diagram of the interface for an interactive method of virtual throwing in one exemplary embodiment of this disclosure is shown. Figure 5 This diagram illustrates the structure of an interactive device for virtual throwing 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

[0012] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0013] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0014] It should be understood that in the embodiments of this application, "at least one" refers to one or more, "several" refers to one or more, and "more than" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "Contains A, B, and / or C" means containing any one, two, or three of A, B, and C.

[0015] It should be understood that in the embodiments of this application, "B corresponding to A", "B corresponding to A", "A corresponds to B" or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0016] The interactive method for using game items provided in this application embodiment can be executed by an electronic device, which can be... Figure 1 The device in question is a terminal 110 or a server 120. The terminal can be a smartphone, tablet, laptop, or other similar device. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can be hardware or software. When the server is hardware, it can be implemented as a distributed server cluster composed of multiple servers or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., software or software modules used to provide distributed services) or as a single software program or software module. This application does not specifically limit the implementation in this regard.

[0017] In one alternative embodiment, taking a game as an example, when the interaction method used by in-game items is running on a terminal device, the terminal device stores the game application and the game's virtual scene. The terminal device interacts with the player through a sender's graphical user interface. The terminal device can provide the sender's graphical user interface to the player in various ways, such as rendering it on the terminal device's display screen or presenting it via holographic projection.

[0018] In an optional embodiment, taking cloud gaming as an example, when the interaction method used by items in the game runs on a server, this method can be implemented and executed based on a cloud gaming system. A cloud gaming system refers to a gaming method based on cloud computing. A cloud gaming system includes servers and client devices. The main body running the game application and the main body presenting the game screen are separate. The storage and operation of the methods for controlling vehicles in the game are completed on the server. The presentation of the game screen is completed on the client, which is mainly used for receiving and sending game data and presenting the game screen. For example, the client can be a display device with data transmission capabilities located close to the player, such as a mobile terminal, television, computer, PDA, personal digital assistant, head-mounted display device, etc. However, the terminal device for processing game data is the server in the cloud. When playing the game, the player operates the client to send instructions to the server. The server controls the game to run according to the instructions, encodes and compresses the game screen and other data, returns it to the client via the network, and finally, the client decodes and outputs the game screen.

[0019] This application provides an interactive method, apparatus, electronic device, and computer-readable storage medium for using items in a game. The control device for the interactive method for using items in the game can be integrated into a computer device, and the electronic device can be a server, a terminal, or other similar device.

[0020] According to one embodiment of the virtual throwing 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 the game scene, and the game scene includes at least one virtual character, such as... Figure 2 As shown, the method may include: Step S210: Provide a first throwing operation control in the graphical user interface. The first throwing operation control is configured with a first partition and a second partition, wherein the first partition is used to trigger a high throw and the second partition is used to trigger a low throw. Step S220: Detect the spatial relationship between the virtual character and virtual obstacles in the game scene; Step S230: When the spatial position relationship meets the preset conditions, a second throwing operation control is provided in the graphical user interface. The second throwing operation control is configured with a first partition, a second partition and at least one third partition. The third partition is used to trigger a lateral throw. Step S240: In response to a sliding operation on the first or second throwing control, determine the throwing trajectory of the virtual prop.

[0021] According to one embodiment of this disclosure, the throwing trajectory is determined by dynamically switching control partitions and responding to sliding operations, which simplifies the interaction path of lateral throwing, helps to reduce the computational load of the terminal in the process of physical rebound detection and trajectory simulation, and reduces additional interface control rendering overhead, thereby improving interaction efficiency and resource utilization.

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

[0023] In step S210, a first throwing operation control is provided in the graphical user interface. The first throwing operation control is configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw, and the second partition is used to trigger a low-throw throw. In this way, by integrating a single throwing control into a dual-partition structure that combines high-throw and low-throw triggering functions, not only is the redundant space occupied by control elements in the graphical user interface reduced, making the main interface more open, but also the player does not need to operate back and forth between independent mode switching controls, significantly improving the convenience and responsiveness of throwing direction selection.

[0024] The following example illustrates the scenario where a player is preparing to throw a virtual item behind cover in an open area: For example, ... Figure 3 As shown, the first throwing control presented in the graphical user interface can be designed as a single touch area, either circular or rounded rectangular. This area is divided into upper and lower halves by a horizontal dividing line. The upper half, designated as the first section, is marked with an upward arrow; when the player touches this area, the system generates a high-angle, high-trajectory trajectory. The lower half, designated as the second section, is marked with a downward arrow; when the player touches this area, the system generates a low-trajectory trajectory close to the ground. It should be noted that the size, transparency, and fixed position of this control on the screen can be adapted to the display ratio of the terminal device and the player's touch habits. For example, on a mobile phone, it can be displayed in the lower right corner for easy thumb control when holding the device with one hand; on a tablet, the touch area can be appropriately enlarged to reduce the probability of accidental touches.

[0025] Optionally, the first throwing control can be a circular, square, or rounded rectangular touch button, designed to receive player press or swipe triggers to control the throwing method of the virtual item and dynamically switch the partition display mode. Alternatively, such as... Figure 3As shown, the aforementioned first throwing control can be a circular touch button located in the lower right corner of the graphical user interface, or a semi-transparent control area spanning the right edge of the screen. Its specific form can be adjusted according to the screen ratio of the terminal device and the player's operating habits. Considering that in fast-paced shooting battles, players need to focus their main visual attention on the dynamic enemy in the center of the scene, distributing multiple independent throwing-related buttons throughout the interface would not only cause a significant shift in focus but also lead to missed opportunities due to frequent button searches. Therefore, as a possible implementation, the aforementioned first throwing control integrates both high-throw and low-throw triggers into a single control. When the player switches to a throwable virtual item, the control automatically appears in a preset fixed position. Players do not need to search for the operation entry in additional drop-down menus or switching bars, effectively reducing cognitive load and improving the responsiveness of tactical actions. Furthermore, the control can also present differentiated visual states at different game stages. For example, it can remain hidden or semi-transparently weakened when the player does not hold a throwable item, while enhancing brightness and edge lighting effects when holding it, thus clearly indicating the current operable state. Optionally, to avoid the absolute stillness of the touch area causing players to have difficulty quickly locating their target during intense battles, the control can also be configured with a slight breathing-style scaling animation or positioning guide lines. Its display level is always above the scene screen and is not obscured by background light and shadow, ensuring that players can complete the throwing preparation immediately from any perspective.

[0026] Optionally, the first zone can be a geometric area located in the upper half of the first throwing operation control, designed to receive upward touch commands to trigger the virtual item to fly out along a high-arc arc. Optionally, the first zone can be a fan-shaped area occupying the upper half of the circular control, or a rectangular color block on the upper side of the square control, whose boundary can be visually distinguished from the second zone by color fill differences, semi-transparent masks, or thin line divisions. In addition to containing basic directional indicator graphics, this zone can also be further overlaid with dynamic light effects, texture patterns, or text prompts to enhance the recognizability of the target location. It should be noted that the above description of the shape and visual style of the first zone is only one example, and this disclosure is not intended to limit the composition of the zone. In actual implementation, in order to avoid players accidentally triggering the high-arc attack due to accidental touch during high-speed movement, the first zone can also be configured with a minimum press area threshold or a minimum press duration threshold. Only when the touch coverage area exceeds the threshold or the press time meets the requirements will the operation be recognized as a valid trigger for the first zone. In addition, in some scenarios, the first partition can also be linked with a gyroscope sensor or an accelerometer sensor. When the system detects that the player quickly lifts the terminal device, it automatically determines that there is an intention to throw it high and assists in activating the corresponding command of the partition. This disclosure does not limit this.

[0027] Optionally, the second zone can be a geometric area located in the lower half of the first throwing control, designed to receive downward touch commands to trigger the virtual item to roll close to the ground. Alternatively, the second zone can be a fan-shaped area in the lower half of the circular control, or a strip of touch extending horizontally along the bottom edge of the square control. Its color depth or surface texture can create a warm / cool contrast or a light / dark contrast with the first zone, helping players quickly locate the operation area using visual inertia. Considering that low-throwing is typically used to accurately deliver virtual items behind cover or into narrow passages, its release height and initial velocity parameters often differ from high-throw trajectories. As a possible implementation, after the second zone is triggered, the system can automatically set the vertical component of the virtual item's initial velocity vector to a smaller value and keep the horizontal forward component at a higher level, based on the low-throw trajectory parameters corresponding to that zone, thereby generating a rolling or low-arc flight trajectory close to the ground. It should be understood that when a player simultaneously performs a sliding operation across the boundaries of the first and second zones, the system can either prioritize the area that is covered first as the effective trigger source, perform a weighted calculation based on the position of the touch point's center of gravity, or directly identify it as a continuous cross-zone sliding and switch to the corresponding throwing arc adjustment mode. The specific anti-accidental touch and mode switching logic can be set according to actual interaction needs, and this disclosed embodiment does not limit this.

[0028] In step S220, the spatial relationship between the virtual character and virtual obstacles in the game scene is detected. This continuous perception of the relative geometric state between the character and physical obstructions provides a precise trigger for switching the throwing control zones, enabling the side-throw function to activate in near-wall scenarios, effectively avoiding false triggers and improving environmental adaptability. In one implementation, taking a top-down tactical shooting scenario as an example, when the virtual character moves near the corner of a building, the game client, during each frame update, fires multiple detection rays from the character's current position to a horizontal fan-shaped area (including the arc-shaped area to the side and rear of the body) extending 15 degrees to the left and right of the crosshair. After obtaining the ray hit results, the system determines whether the hit scene object has a wall semantic label and whether its collider height is higher than the virtual character model height, while simultaneously calculating the horizontal distance between the obstacle and the character's center point. If this distance is within a preset threshold range (e.g., between 0.5 meters and 5 meters), the virtual character is marked as being against a wall on the left or right, thus providing a precise scene trigger for dynamically switching the throwing button from two zones to four zones.

[0029] Optionally, the virtual obstacle, serving as a spatial reference for triggering lateral throwing, can be a geometric object or building component with blocking properties in the scene. Alternatively, the aforementioned virtual obstacle can be configured as an environmental construct with entity collision properties in the game scene, such as a wall, building facade, or terrain cover with specific semantic labels. Considering that the lateral throwing function requires physical obstructions to achieve a realistic trajectory curvature, as a possible implementation, the height parameter of the virtual obstacle can be set to be higher than the height of the virtual character model. This ensures that only obstacles with sufficient vertical dimensions can trigger the lateral throwing mechanism, preventing low-lying obstacles or item boxes from being mistakenly identified as valid references. The geometry of the virtual obstacle can be a vertical plane, an arc surface, or a three-dimensional structure with irregular contours. The direction of its surface normal will directly affect the system's determination of the wall-facing direction. This disclosure is not intended to limit the specific visual representation of the virtual obstacle.

[0030] Optionally, the aforementioned virtual obstacles can be fixed scene walls or dynamic scene elements with blocking properties, such as destroyable cover, temporary defensive barriers, or stationary scene vehicles. To avoid detection failures due to differences in obstacle material properties, the system can determine the obstacle based on the existence of colliders rather than visual visibility. That is, even if the obstacle is semi-transparent or damaged, it is considered a valid virtual obstacle if its colliders are not destroyed. It should be understood that in narrow passages or scenes with obstacles on both sides, the system can record the detection results on the left and right sides separately, and accordingly activate the two third zones on the left and right sides simultaneously on the graphical user interface, thus providing players with a two-way side-projection operation entry point.

[0031] Optionally, to improve the stability of the detection results and reduce the risk of false triggers caused by momentary jitter, a multi-frame buffer verification mechanism can be introduced into the above-mentioned virtual obstacle recognition process. Specifically, the system can perform ray detection or collision range detection in consecutive frames, and only if it maintains continuous hits within a preset number of frames will the virtual character be marked as a stable wall-leaning state. Furthermore, if the player moves away from the wall while holding down the side-throw zone, the system can maintain the currently adjusted throwing arc and allow the release operation to continue, or it can smoothly transition to the forward throwing mode based on the real-time detection results; this disclosure does not limit this. It should be noted that the obstacle judgment threshold can be dynamically adjusted according to the virtual character's current posture or game mode to adapt to the detection needs of different body positions such as prone and crouching.

[0032] Optionally, the spatial positional relationship represents the relative geometric state between the virtual character and the obstacle, and may include straight-line distance, azimuth angle, or height difference.

[0033] Optionally, the aforementioned spatial relationship can be quantified as multi-dimensional geometric parameters between the virtual character and the virtual obstacle. This includes not only the straight-line distance between them on the horizontal plane, but also the relative azimuth angle based on the character's orientation and the vertical height difference between the obstacle and the top of the character's head. As a specific implementation, the system can use the player's current crosshair direction as a reference axis and emit detection rays to a fan-shaped area 15 degrees to the left and right of this axis. This allows the acquisition of the spatial coordinates of the hit point and the calculation of the aforementioned distance and angle parameters. The determination of this spatial relationship directly determines whether the virtual character is marked as being against a wall on the left or right, thus providing a data basis for switching the partition mode of the subsequent throwing operation controls.

[0034] Optionally, to avoid visual interference caused by frequent switching of the throwing control due to extremely brief wall-skimming or network fluctuations, the spatial position detection process can introduce a dual constraint mechanism of preset distance threshold and angle range. Specifically, the system will only trigger the display logic of the second throwing control if the straight-line distance between the virtual character and the virtual obstacle is less than or equal to the preset distance threshold, and the obstacle is within a detection sector at least 15 degrees to the left or right of the crosshair direction. It should be noted that the above threshold and angle range can be flexibly configured according to different game modes or map characteristics, aiming to balance operational convenience and scene realism, and to prevent players from accidentally triggering the lateral throwing function in large open areas far from walls.

[0035] In an optional implementation, detecting the spatial relationship between the virtual character and virtual obstacles includes detecting the spatial relationship between the virtual character and virtual obstacles within a preset angle range of the current viewpoint direction. By limiting wall detection to a preset angle range of the viewpoint direction, the resource overhead of omnidirectional scanning can be avoided, and false detections in non-interested areas can be eliminated, making side-projection triggering more consistent with actual combat scenarios and improving detection efficiency and accuracy. In one implementation, the client uses the virtual character's current viewpoint direction as the detection reference axis, searching for virtual obstacles within sectors formed by offsetting a specified angle to the left and right of this reference axis; for example, the preset angle range can be set to a sector area of ​​45 degrees to the left and right of the viewpoint direction. The system only emits detection rays or performs collision queries within this sector to determine whether there are walls within a certain threshold distance from the character and exceeding the height of the character model. In another approach, the preset angle range can also be set to the outer area excluding the main field of view directly in front, allowing detection to focus on obstacles to the side and rear of the character, avoiding interference from objects in non-side-projection related areas in determining spatial relationships.

[0036] Optionally, the preset included angle range is designed to define the detection sector based on the current viewpoint direction, and its angle boundary can be configured according to scene requirements.

[0037] Optionally, the aforementioned preset angle range can be an outer area beyond 15 degrees to the left and right of the viewing direction, or a fan-shaped area at 30 degrees, 45 degrees, or other angles to the left and right; this disclosure does not limit this. Considering that in actual combat scenarios, the player's effective observation range is mainly concentrated in the frontal field of view and the areas on both sides, as a possible implementation method, the detection range is set to a specific sector centered on the current viewing direction. On the one hand, this can effectively reduce the computational overhead of ray detection or collision query, avoiding indiscriminate traversal of non-interested areas; on the other hand, it can make the side-projection trigger logic more aligned with the player's current tactical observation orientation. Furthermore, the boundary angle value of this angle range is not only related to the competitive rhythm of the game type, but can also be comprehensively configured in conjunction with the width of the passage and the density of the walls on the map. Developers can adjust this angle parameter in the configuration tool based on actual testing experience to achieve a balance between detection sensitivity and false trigger rate, thereby ensuring that the activation conditions of the side-projection function remain reasonable in various combat scenarios.

[0038] Optionally, in addition to using a fan-shaped or annular area with a fixed angle value as the aforementioned preset angle range, this range can also be dynamically shifted according to the relative orientation between the virtual character and the virtual obstacle. For example, when the system detects that the left side of the virtual character is close to the wall while the right side is an open area, the aforementioned preset angle range can be shifted to the left by a certain angle based on the current viewing direction, prioritizing coverage of the extension direction of the left wall; similarly, when the character is sideways against the wall and facing the corner of the passage, the angle range can also be temporarily expanded to the boundary facing the corner. It should be noted that the judgment logic of this dynamic shift not only refers to the real-time orientation of the virtual character, but can also combine the wall orientation data identified in the previous detection cycle for a smooth transition, so as to avoid high-frequency jumps in the angle range caused by small viewing adjustments or standing still by the virtual character, thereby ensuring the stability of the detection process and the continuity of the side projection trigger judgment.

[0039] In step S230, when the spatial relationship meets preset conditions, a second throwing operation control is provided in the graphical user interface. The second throwing operation control is configured with a first partition, a second partition, and at least one third partition, with the third partition used to trigger a lateral throw. In this way, by dynamically expanding the throwing button into a multi-partition control including a lateral partition, players can intuitively trigger lateral throws, effectively enriching the operational dimensions of the thrown object, avoiding the limitations of over-reliance on terrain bounce in conventional solutions, and improving the flexibility and scene adaptability of human-computer interaction.

[0040] In one implementation, such as Figure 4As shown, players control a virtual character to move in a street battle scene. When the character gets close to the left-hand building wall and the distance is less than a preset threshold, the system determines that the spatial relationship meets the preset conditions. The throwing control in the graphical user interface then dynamically switches from the first throwing control with two sections (upper and lower) to the second throwing control with four sections (upper, lower, left, and right). The third section on the left is activated as a side-throw entry point. Players can click on this third section on the left and slide it left or right to control the projectile to be thrown sideways towards the left corner. Optionally, the preset conditions are used to define the critical state where the spatial proximity between the virtual character and virtual obstacles reaches the point of triggering the side-throw function.

[0041] Optionally, the preset conditions can be at least one or more combinations of distance conditions, angle conditions, or height conditions. Considering the balance between the accuracy and performance overhead of wall detection in shooting games, as a possible implementation, the preset conditions at least include that the horizontal distance between the virtual character and the virtual obstacle is less than or equal to a preset distance threshold. This threshold can be set to values ​​such as 0.5 meters, 1.5 meters, or 5 meters, and can be dynamically adjusted according to the scale of the game scene and the effective side-throw range of the projectile. It should be noted that the above description of the preset conditions is only one example. In actual implementation, the height of the virtual obstacle can be further determined, that is, only obstacles with a height higher than the height of the virtual character model can be regarded as effective walls to avoid low cover from mistakenly triggering the side-throw zone. In addition, the preset conditions can also include view direction constraints, such as only taking effect when a wall is detected outside 15 degrees to the left or right of the current view direction or in the area behind it, thereby reducing erroneous UI switching caused by directly hitting a wall.

[0042] Optionally, the preset conditions can be adaptively set according to the passage environment in which the virtual character is located. In practical applications, when the player character is in a narrow passage with walls on both sides, the preset conditions can be configured to simultaneously detect virtual obstacles in both directions. When the distance requirements on both sides are met, the left and right third zones of the second throwing control are activated simultaneously, allowing the player to choose to throw to the left or right according to tactical needs. To avoid detection ambiguity caused by differences in the distance between the walls on both sides, the preset conditions can also set direction priority judgment logic. For example, the side with the closer distance can be used as the first priority activation direction, or the zone on the opposite side of the crosshair offset direction can be activated by default when the distances on both sides are equal. Furthermore, the preset conditions can also introduce a time-dimensional stability check, requiring that the spatial positional relationship between the virtual character and the virtual obstacle continuously meet the preset conditions for a preset duration before triggering the zone switching, in order to avoid frequent changes in the control state caused by the character briefly passing over the edge of the wall.

[0043] Optionally, the second throwing operation control is configured with a first partition, a second partition, and a third partition, which is a multi-partition throwing interaction carrier that is dynamically provided when preset conditions are met.

[0044] Optionally, the second throwing control can be presented in the graphical user interface as a circular, rounded rectangle, or fan-shaped area, with multiple functional zones formed internally by line divisions, color blocks, or differences in transparency. This control can be placed in the lower right or lower left corner of the graphical user interface, adjacent to the movement joystick but not overlapping, or it can float in the lower center of the screen for easy one-handed operation. It should be noted that the second throwing control does not necessarily completely replace the original first throwing control. Instead, it can smoothly transform and expand from the first throwing control through a transition animation when the player switches to a throwing item. For example, the dividing line between the upper and lower zones extends to both sides, gradually revealing two third zones on the left and right. During different stages of gameplay, if the virtual character detaches from the wall, causing the spatial relationship to no longer meet the preset conditions, the second throwing control can shrink back to the two-zone form of the first throwing control.

[0045] Optionally, the visual presentation parameters of each section in the second throwing control can be dynamically adjusted according to its current availability. Specifically, when the spatial relationship of the third section meets the preset conditions and there is a projectile wall in the corresponding direction, it can be presented as a highlighted, glowing, or colored marker to indicate to the player that the side throwing direction is available; while the third section on the opposite side or the section that does not currently meet the trigger conditions can be weakened by being grayed out, semi-transparent, or desaturated. Furthermore, to avoid accidental touches by players in tense shooting scenarios, each section of the second throwing control can have an independent touch hotspot, and a preset width of visual gap or physical isolation zone is maintained between each hotspot. For example, when the upper section and the left third section are adjacent, a non-responsive transition edge can be set between them, so that when the player presses the upper section, they will not accidentally slide into the left third section, thereby ensuring that the boundaries of the high throw and side throw commands are clear.

[0046] Optionally, the second throwing control can also respond to combined touch operations to support the triggering of composite throwing modes. Considering that players may need to adjust the throwing height and lateral arc simultaneously during tactical throwing, as a possible implementation, when the player simultaneously presses the third section and the first section and slides in the corresponding direction, the system can determine it as a lateral throw with a high-arc mode; similarly, pressing the third section and the second section simultaneously corresponds to a lateral throw with a low-arc mode. The judgment logic of this combined operation can be based on the distribution of touch point landing points. For example, when the geometric center of two touch points falls on the boundary area between the first and third sections, or when the touch area of ​​a single touch point simultaneously covers both sections, the composite mode is triggered. It should be noted that in composite mode, the original height adjustment function of the first and second sections can be executed in parallel with the lateral arc adjustment function of the third section without interference, allowing players to complete multi-dimensional throwing trajectory settings with a single finger swipe.

[0047] Optionally, the third partition is used to receive lateral throwing trigger operations, and its quantity and activation state are dynamically determined based on the detection results of spatial position relationships. Optional, such as... Figure 4 As shown, the third section in the second throwing control can be represented as a fan-shaped area, an arc-shaped strip, or a rectangular block with directional arrows on the left or right. The specific layout of this section corresponds to the direction of the wall the virtual character is near. For example, when the system detects a wall to the left of the virtual character and meets preset conditions, the left third section is activated and operable, while the right third section can remain hidden or disabled. It should be noted that the number of third sections is not limited to one; in narrow passages or scenarios with walls on both sides, both left and right third sections can be activated simultaneously. Furthermore, in addition to single-click triggering, the third section can also be configured to receive combined input of long-press and swipe gestures. Players can press and hold the third section and slide it horizontally to adjust the lateral curvature of the throwing trajectory in real time while maintaining the lateral throwing direction.

[0048] Optionally, the third zone can also be configured with edge protection mechanisms and swipe error-tolerant logic at the touch response level. To prevent players from accidentally entering the adjacent first or second zone due to finger deviation when clicking the third zone, a preset width of invalid touch buffer can be set at the edge of the third zone facing the adjacent zone. This buffer does not respond to swipe operations or only responds to swipe gestures towards the inside of the third zone. In addition, when the player presses and holds the third zone and swipes away from the adjacent zone, the system determines that the lateral throwing arc is increased; while when the player accidentally swipes towards the adjacent zone, the system can filter or map the swipe component to the minimum arc value, thereby maintaining the basic direction of the lateral throwing unchanged. It should be understood that the touch hotspot of the third zone can be slightly larger than its visual display range to improve the touch hit rate in small screen scenarios on mobile devices, but on large screens or tablet devices, the touch hotspot can also be strictly aligned with the visual boundary.

[0049] Optionally, lateral throwing is a throwing method that is triggered by the third zone when the spatial position relationship meets the preset conditions, causing the virtual prop to be thrown sideways along the character.

[0050] Optionally, lateral throwing allows the virtual item to deflect at a preset angle relative to the character's forward direction on a horizontal plane. This deflection angle can be adjusted in real-time by the player's sliding operation on the third section. Considering the force limitations of a human throwing laterally in a real physical environment, the deflection arc of the lateral throw can be constrained within a preset maximum arc, such as between 0 and 30 degrees, to ensure that the throwing trajectory is both physically consistent and tactically controllable. As a possible implementation, the initial velocity of the lateral throw can be consistent with that of a regular forward throw, but its velocity vector includes a composite of forward and lateral components, where the magnitude of the lateral component increases accordingly with the increase of the deflection angle. Furthermore, lateral throwing can also be combined with high-throw or low-throw modes, that is, the player can press the first or second section while holding down the third section, so that the virtual item has the parabolic height characteristics of a high-throw or low-throw while deflecting laterally.

[0051] Optionally, the side throw can be accompanied by adaptive adjustments to the character animation at the moment of release. For example, the virtual character's arm holding the object can swing to the corresponding side, and the body's center of gravity can shift accordingly to enhance the visual feedback and immersion of the side throw. In terms of trajectory prediction, the system can calculate and render a parabolic preview trajectory with curvature in real time based on the current lateral deflection angle, initial velocity, and gravitational acceleration parameters. This preview trajectory can be displayed as a dashed line or a semi-transparent light band and projected onto the ground and wall surfaces in the game scene. It should be noted that the preview trajectory of the side throw can only show the path from the release point to the first collision, or it can continue to simulate the trajectory after the bounce based on the scene's geometry; this disclosure does not impose any limitations on this. Furthermore, to prevent players from accidentally releasing the object by holding down the third section for an extended period while waiting for the optimal moment to throw, the system can provide a subtle vibration or sound effect to indicate that the player is in a ready-to-release state after the player has held down the button for a preset duration.

[0052] In an optional implementation, the spatial relationship meets preset conditions, including: the distance between the virtual character and the virtual obstacle is less than or equal to a preset distance threshold. Thus, by quantifying the spatial relationship as a comparison between the judgment distance and the preset threshold, a clear and dynamically adjustable quantitative basis can be provided for side-projection triggering, reducing interaction misjudgments caused by ambiguity in collision determination.

[0053] For example, the preset distance threshold can be flexibly set according to the scene collision detection mechanism. For instance, in an implementation primarily using ray detection, the threshold can be set to 0.5 meters. When the distance between the virtual character and the surface normal of a virtual obstacle is less than or equal to this value, the system determines that the side-throw trigger condition is met. In another implementation, if a bounding box overlap detection mechanism is used, the threshold can be set to 5 meters. When the shortest distance between the outer contour of the virtual character and the boundary of a virtual obstacle is less than or equal to this value, it is also considered that the preset condition is met. Furthermore, the preset distance threshold can also be configured differently based on the type of projectile. For example, a smaller threshold can be used for melee explosives, and a larger threshold can be used for tactical cover projectiles, thereby reasonably balancing the sensitivity and risk of accidental triggering of side-throw triggering in different combat scenarios.

[0054] Optionally, the preset distance threshold is used to quantify the proximity between the virtual character and obstacles, serving as a criterion for triggering side-projection zone switching. Optionally, the preset distance threshold can be set in conjunction with the calculation results of ray detection or collision detection. In one embodiment, the game client emits a detection ray centered on the current position of the virtual character, extending to an area beyond 15 degrees to the left and right of the current view direction (including the area behind the character). When the ray hits a scene object labeled with an obstacle and the calculated straight-line distance is less than or equal to a preset distance threshold (e.g., 5 meters), the triggering condition is considered met. In another embodiment, the client determines whether there are virtual obstacles within a preset range around the virtual character through collision range detection, and calculates the shortest distance between the outer boundary of the virtual character's collision body and the inner boundary of the virtual obstacle's collision body. When this shortest distance is less than or equal to another preset distance threshold (e.g., 0.5 meters), the subsequent side-projection interaction logic is also triggered. It should be noted that the above description of the detection method and specific values ​​is only one example. This disclosure is not intended to limit the size or calculation form of the threshold. In actual implementation, it can be determined according to the rhythm of different gameplay, map scale or character movement speed. For example, in fast-paced battle scenarios, the threshold can be appropriately increased to improve the operation response speed, while in realistic tactical scenarios, the threshold can be reduced to strictly simulate the closeness of physical space.

[0055] Optionally, considering that a single static threshold may lead to oversensitivity or sluggish response in different game scenarios, as a possible implementation, the aforementioned preset distance threshold can be configured as a parameter that dynamically changes with the game context. Furthermore, this preset distance threshold can be differentiated based on the type of throwable item held. For example, when holding a fragmentation grenade, the threshold can be reduced to 2 meters to avoid accidental triggering of the side-throw interface in wider corridors; when holding a smoke grenade, the threshold can be increased to 6 meters to allow earlier entry into the side-throw preparation state. In multiplayer scenarios, this threshold can also be further correlated with faction / role attributes. For example, reconnaissance characters may use a larger threshold due to tactical close-range requirements, while sniper characters may use a smaller threshold to maintain operational accuracy in concealed positions. It should be understood that in scenarios where the virtual character moves at a high speed, the preset distance threshold can be positively compensated based on the speed status; that is, the faster the movement speed, the higher the threshold should be, to reserve a response buffer for interface switching in advance, thus ensuring that the side-throw trigger determination has both spatial tolerance and operational responsiveness.

[0056] In step S240, in response to a sliding operation on the first or second throwing control, the throwing trajectory of the virtual item is determined. This allows players to continuously adjust the flight path of the projectile with a single finger swipe, significantly improving the accuracy and immersion of the throwing operation while eliminating the need for additional interface elements. In one implementation, the player controls the virtual character close to the left wall. The graphical user interface displays a second throwing control with a four-section structure. The player presses their finger on the left section of this control and continuously slides to the left. The system collects the horizontal displacement generated by this sliding operation in real time and converts it into a lateral throwing arc value using a preset mapping function. Then, combining the release height and initial velocity parameters, the system determines the complete throwing trajectory of the virtual item from the character's hand, after a lateral bend, to the target area. In another scenario, when the player is in an unobstructed open area and the interface only displays the first throwing control in the upper and lower sections, the player applies an upward swipe gesture to the upper section. The system fine-tunes the release angle and landing distance of the high-throw trajectory based on the vertical displacement of this swipe, similarly determining the flight trajectory of the virtual item.

[0057] Optionally, the swipe operation is a continuous touch-and-displacement gesture performed by the player on the zone control, used to map the touch displacement to throwing trajectory parameters. Optionally, the above swipe operation specifically manifests as a press-and-swipe gesture performed by the player on the touch screen for either the first or second throwing control. In side-throw mode, the player presses and holds the left zone of the second throwing control and drags it in a specific direction. The system uses the press start point as the coordinate origin, collects the touch point position frame by frame, and calculates the horizontal displacement increment. This displacement increment is converted into a side-throw arc value after linear mapping processing, where every two pixels of movement corresponds to one degree of deflection angle, and the maximum deflection angle is limited to within 30 degrees to ensure that the throwing arc conforms to physical laws and avoids excessive bending that leads to an unnatural trajectory. During this process, the swipe direction is consistent with the preset throwing direction of the third zone. For example, swiping away from the adjacent zone increases the side-throw arc, while swiping towards the adjacent zone keeps the side-throw arc at its minimum, thus establishing an intuitive directional correspondence.

[0058] Optionally, besides the implementation based on single-finger horizontal swipe mapping of radians, the aforementioned swipe operation can also be configured as a two-finger opening and closing or circular swipe gesture to provide a wider range of radian adjustment precision within the limited screen space. For example, when a finger performs a clockwise circular swipe on a lateral partition, the system calculates the lateral radian increment based on the change in the central angle; a counter-clockwise circular swipe decreases the radian. Furthermore, to reduce the risk of misadjustment due to slight hand tremors, the system can set a very small dead zone threshold at the initial stage of the swipe, only initiating trajectory calculation after the touch point displacement exceeds this threshold. If the player's finger pauses temporarily during the swipe, the system freezes the current radian value on the preview line, continuing to accumulate or decrease it upon resuming the swipe, thus balancing operational error tolerance and adjustment continuity.

[0059] Optionally, during the player's swipe action, such as Figure 4 As shown, the graphical user interface renders a real-time preview line of the throwing trajectory connecting the character's hand and the predicted landing point. This preview line dynamically bends with the touch point's displacement, and its curvature is strictly synchronized with the lateral throwing arc determined by the current swipe operation. If the system detects that the player's finger slides out of the lateral zone and enters the adjacent high-throw or low-throw zone during the swipe, it is determined to be a combined trigger state. The current lateral arc is superimposed with the high-throw or low-throw parameters to generate a composite throwing trajectory with both lateral offset and height change. In this case, the preview line is updated to a curved parabola in three-dimensional space, allowing the player to intuitively judge whether the thrown object accurately crosses the wall and reaches the target area before releasing the hand, significantly improving the controllability of throwing operations in complex terrain.

[0060] Optionally, the throwing trajectory is the flight path of the virtual item after it is thrown, and its shape and parameters are determined in real time by the swipe operation. Optionally, the throwing trajectory is geometrically represented as a parabolic curve affected by gravitational acceleration, with its specific parameters determined by the initial velocity vector, lateral curvature correction, and release height. In lateral throwing mode, the system uses the character's hand position as the starting point and, based on the lateral curvature value mapped by the current swipe operation, superimposes a horizontal lateral component onto the basic forward velocity, causing the parabola to exhibit a flight path that curves towards the target side in the air. The amplitude of this lateral component is limited to the range of trigonometric function values ​​corresponding to a preset maximum curvature to ensure that the landing point is always within a reasonable area in front of the player. Simultaneously, the client generates a preview curve in the game scene based on these parameters, composed of multiple trajectory points, typically presented as a dashed line or semi-transparent material, to help the player predict the final landing point and flight time of the virtual item before release.

[0061] Optionally, the throwing trajectory can be dynamically refreshed based on real-time changes in the player's swipe actions. When the player presses and holds the lateral section and changes the swipe distance, the trajectory preview line stretches or contracts its lateral curvature in the air accordingly. The entire refresh process is performed at a frequency of no less than 30 frames per second to ensure visual continuity. If the player suddenly swipes in the opposite direction during the swipe, the system instantly recognizes the change in displacement direction and reduces the lateral throwing arc accordingly. It may even switch the lateral throwing direction to the opposite side after the player swipes in the opposite direction past the origin. In addition, in some implementations, the trajectory calculation module may also introduce air resistance coefficients or wind direction interference factors to make the preview line present a more realistic drop and swaying shape, thereby providing a more strategic and environmentally adaptable throwing experience in highly realistic shooting games.

[0062] In an optional implementation, determining the throwing trajectory of the virtual item in response to a sliding operation on the first or second throwing control includes: determining the throwing direction and throwing arc of the virtual item in response to a sliding operation on the first or second throwing control. Thus, by integrating the determination of the throwing direction and throwing arc into a single sliding operation, players can complete direction selection and angle fine-tuning in a single continuous touch, reducing the amount of UI controls used and improving the continuity and efficiency of side-throwing operations.

[0063] In one implementation, when a player presses the third section on the left side of the second throwing control and slides it to the left, the system recognizes the touch as a leftward throwing direction and calculates the throwing arc based on the sliding distance at a linear ratio of one degree per two pixels. Finally, the system updates the parabolic trajectory preview with the corresponding curvature in real time on the graphical user interface. If the player presses the third section on the left side and the first section on the top side at the same time and slides it to the left, the system superimposes the high-angle in the leftward throwing direction to generate a composite throwing trajectory that combines lateral deflection and high-angle characteristics.

[0064] Optionally, the throwing direction represents the initial direction of motion of the virtual prop after it leaves the virtual character, determined by the operation applied to the throwing control. Optionally, the throwing direction may include, but is not limited to, high-throw direction, low-throw direction, left-hand throwing direction, and right-hand throwing direction. The high-throw direction corresponds to the state where the virtual prop leaves the virtual character at a high initial angle of elevation and moves along a parabola with a large curvature; the low-throw direction corresponds to the state where the virtual prop quickly approaches the ground at a low initial angle of elevation; the left-hand and right-hand throwing directions correspond to the motion states of the virtual prop with added lateral components during its forward movement. In actual interaction, the above directions are not isolated from each other, but can be combined and invoked in the same touch operation; for example, when the touch input simultaneously covers the third and first zones and slides to the left, the system can recognize the input as a composite command of left-hand throwing direction plus high-throw height. It should be noted that the specific number of throwing directions is not limited to four; it can be expanded into more subdivided directions according to the depth of gameplay and interaction design needs, or high-throw and low-throw can be merged into a single forward throwing direction. This disclosure does not limit this.

[0065] Optionally, the throwing direction determination logic can be dynamically based on the geometric center of the touch area or the density distribution of touch points. As one possible implementation, when a touch point simultaneously falls into the boundary area between the first and third zones, the system can calculate the touch area ratio or pressure sensitivity value of the two zones, and consider the side with the higher ratio as the primary direction and the other side as the auxiliary correction direction. For example, if the touch area ratio of the third zone on the left exceeds 60%, while the ratio of the first zone is approximately 40%, the throwing direction is determined as a basic leftward direction with a moderate high-throw correction. To avoid sudden changes in direction due to finger deviation, the above determination process can also introduce a time window filtering mechanism, i.e., collecting touch area distribution data over multiple consecutive frames, and updating the current throwing direction only after the primary direction zone ratio continuously meets the threshold condition for a specified duration. It should be understood that the touch sampling accuracy varies across different terminal devices; therefore, the threshold and duration of the aforementioned area ratio can be adjusted for hardware performance or player-defined preferences.

[0066] Optionally, the throwing arc represents the degree of deflection of the lateral trajectory of the virtual prop relative to the forward launch direction, and is obtained by sliding distance mapping.

[0067] Optionally, the throwing arc is used to quantify the degree of deflection of a virtual item relative to the direction the virtual character is facing when it is thrown laterally. This can be determined through a mapping relationship between the sliding displacement and the arc parameter. Specifically, when the system detects a sliding operation on the third partition, it can obtain the sliding distance of the touch point relative to the initial press position and convert this distance into a corresponding arc value according to a preset mapping ratio; for example, for every two pixels increase in sliding distance, the side-throw arc increases by one degree, until a preset maximum arc value is reached. This mapping relationship can be linear, ensuring an intuitive one-to-one correspondence between the player's sliding input and the trajectory deflection, reducing the learning curve. It should be noted that the setting of the maximum arc value is closely related to the game's physical constraints and gameplay balance. For example, it can be set to thirty degrees to ensure that the virtual item can only achieve effective lateral diffraction when the virtual character is close to a wall and near a corner, avoiding excessively large turning radii that defy physical intuition. In addition, when the sliding direction is consistent with the preset throwing direction of the third section, the arc value increases with the increase of the sliding distance; if the sliding direction is opposite to the preset throwing direction, the arc value can be kept at the minimum value, such as zero degrees, so as to prevent the direction logic confusion caused by reverse sliding.

[0068] Optionally, in addition to the linear mapping mentioned above, the throwing arc can also be determined using a nonlinear mapping strategy, such as exponential or logarithmic mapping, to provide differentiated control precision in different arc ranges. As a possible implementation, a higher mapping sensitivity is used in the small angle range close to zero degrees, allowing players to precisely control slight side throws during micro-management adjustments; a lower mapping sensitivity is used in the range close to the maximum arc, allowing players to lock the arc without excessive screen sliding when side-throwing at large angles. The curve parameters of the aforementioned nonlinear mapping can be dynamically adjusted according to the type of throwing item. For example, grenades require precise control in confined spaces, so a high-precision curve can be used; smoke grenades have relatively lower requirements for landing accuracy, so a fast-response curve can be used. It is important to emphasize that regardless of the mapping function used, the system will perform truncation when the calculated arc value exceeds the preset maximum arc, limiting the actual output arc to the physically permissible range, thereby ensuring that the throwing trajectory always conforms to the scene constraints.

[0069] Optionally, during the sliding adjustment of the throwing arc, the system can also monitor the spatial relationship between the virtual character and virtual obstacles in real time, and trigger a safety transition mechanism when the positional relationship no longer meets the preset conditions. Considering that the player may move during the pressing and sliding process, if the distance between the virtual character and the wall exceeds the preset distance threshold due to movement, the system can maintain the currently selected throwing arc unchanged until the player releases the touch or actively cancels the throw, in order to avoid operation interruption due to sudden changes in state. Furthermore, in order to prevent players from accidentally adjusting the sliding in non-side-throw mode, the system can set a minimum displacement threshold for the sliding operation. The arc adjustment logic is only officially activated when the horizontal displacement exceeds this threshold, and slight touch jitter will be ignored by the filter. On this basis, the client can also synchronize the currently calculated arc value to the throwing trajectory preview module, driving the preview line to bend in real time and present the corresponding parabolic trajectory. This allows players to accurately perceive the landing point trend corresponding to the current arc based solely on visual feedback, without specific numerical prompts, thereby significantly improving the intuitiveness and predictability of side-throw operation.

[0070] In an optional implementation, in response to a trigger operation on the second throwing control, determining the throwing trajectory of the virtual prop includes: acquiring the sliding displacement of a sliding operation on the third partition relative to the touch point, the sliding displacement including the sliding direction and the sliding distance; determining the lateral throwing direction of the virtual prop based on the sliding direction, the sliding direction being consistent with the preset throwing direction of the third partition; and determining the lateral throwing arc of the virtual prop based on the sliding distance, wherein the lateral throwing arc is less than or equal to a preset maximum arc. Thus, by binding the sliding direction to the preset direction of the partition and mapping the sliding distance to the throwing arc, a precise correspondence between the throwing parameters and the touch input is achieved, improving the control accuracy and operational intuitiveness of lateral throwing.

[0071] In one implementation, the player character is positioned against a virtual obstacle on the left. The graphical user interface displays a second throwing control with four sections: up, down, left, and right. When the player touches the third section on the left, the terminal device records the initial coordinates based on the touch point and continuously calculates the sliding displacement between the current touch point and the initial coordinates as the player's finger slides. This sliding displacement includes a horizontal leftward sliding direction and a cumulative sliding distance of 80 pixels. The system compares the sliding direction with the preset leftward throwing direction of the third section on the left, confirming a match and thus determining the lateral throwing direction of the virtual item as a leftward throw. Simultaneously, the system converts the 80-pixel sliding distance into a candidate lateral throwing arc of 40 degrees according to a preset linear mapping rule. However, since the preset maximum arc is limited to 30 degrees, the system automatically truncates the lateral throwing arc to 30 degrees. Furthermore, if the player slides their finger to the right in the opposite direction during the sliding process, the system recognizes that the sliding direction is inconsistent with the preset throwing direction, thus maintaining or resetting the lateral throwing arc to the minimum value of 0 degrees to avoid erroneous reverse side throws.

[0072] Optionally, the sliding displacement is used to quantify the amount of touch drag by the player in the third zone, which is calculated by the coordinate difference between the touch reference position and the real-time touch position.

[0073] Optionally, the sliding displacement can be a two-dimensional vector or a one-dimensional scalar determined by the real-time capture of touch point sequences by the terminal device while the player's finger is pressed and held on the third section. The determination process of this sliding displacement can specifically include: recording the initial coordinates of the touch point in the game view coordinate system when a touch press event is detected; continuously acquiring the current touch point coordinates based on the touch frame update frequency during the player's finger sliding; and performing a difference calculation between the current coordinates and the initial coordinates to obtain the offset in the horizontal and / or vertical directions. This offset constitutes the sliding displacement. In lateral throwing interaction scenarios, to reduce the interference of vertical sliding on the judgment of the lateral throwing arc, the above sliding displacement can primarily extract the horizontal component as the effective sliding displacement, while using the vertical component as an auxiliary judgment or filtering object. In addition, considering the unconscious shaking that players may experience in the early stages of sliding, the above method may also include: determining whether the magnitude of the sliding displacement is greater than a preset minimum displacement threshold. If it is greater, the subsequent throwing direction and throwing arc determination process is initiated. If it is less than, it is considered an invalid touch and ignored, thereby avoiding unexpected changes in throwing parameters caused by slight hand tremors.

[0074] Optionally, the aforementioned sliding displacement can be calculated not only based on the coordinate difference of a single touch point, but also using various alternative quantification methods to characterize the intensity and intent of the player's sliding input. For example, the sliding displacement can be an integral vector of the touch trajectory within a certain time window, the integral result of the touch speed over time, or a composite function of touch pressure change and displacement distance. In some implementations, considering the differences in screen size and resolution of different terminal devices, the sliding distance can be normalized by screen density and converted into a device-independent standardized length unit, then mapped to a lateral throwing arc based on the standardized value. As a possible implementation, the system can also record the peak speed or average speed during the sliding process, incorporating the speed information into the weighted calculation of the sliding displacement. This allows fast and slow sliding, even at the same physical distance, to produce different lateral throwing arc contributions, thereby increasing the control dimensions and adapting to the operating habits of different players.

[0075] Optionally, to avoid confusion in direction and arc determination caused by the player's finger sliding out of the third partition boundary or across partitions during the sliding process, the acquisition of the aforementioned sliding displacement can also include boundary constraints and sub-region division logic. Specifically, the system can further define effective sliding response sub-regions within the third partition. When the touch point is within this sub-region, the sliding displacement is calculated normally. If the touch point moves out of the third partition and enters an adjacent partition, the system can keep the last effective displacement recorded in the third partition as a locked value, or perform a smooth transition based on the preset directional relationship between the sliding direction and the adjacent partition. Furthermore, if the virtual character moves away from the wall-adjusted state during the player's sliding arc adjustment, the system can maintain the currently determined lateral throwing arc and allow the player to continue fine-tuning before releasing their finger until the release operation triggers the throw; alternatively, the system can gradually transition the lateral throwing arc to zero degrees after detecting that the character has moved away from the wall, while simultaneously prompting the player that the current lateral throwing function is about to be turned off, thereby ensuring the continuity of the interaction and the rationality of the physical logic.

[0076] Optionally, the lateral throwing direction is used to indicate the lateral deflection direction of the virtual item, determined based on the matching relationship between the sliding direction and the preset throwing direction of the third section. Optionally, the lateral throwing direction can be a throwing parameter assigned by the system after comparing the directional component of the sliding displacement with the preset throwing direction of the third section itself when the player presses and slides the third section. The preset throwing direction of the third section can be consistent with the spatial orientation of the section in the second throwing operation control. For example, the third section located on the left side of the control is preset to throw to the left, and the third section located on the right side of the control is preset to throw to the right. When the system detects that the sliding direction is consistent with the preset throwing direction, it can determine the lateral throwing direction as the preset direction; if the detected sliding direction is opposite to the preset throwing direction, in order to conform to the player's operating intuition and avoid accidental triggering, the system can limit the lateral throwing arc to a minimum value, while the lateral throwing direction remains the original preset direction of the third section, or the lateral throwing direction can remain in the currently confirmed direction without flipping. It should be noted that the preset throwing direction can be automatically set by the system based on the relative positional relationship between the virtual character and the virtual obstacle when the control is generated, or it can be written into the interaction configuration file as a static parameter by the developer during the configuration phase. The specific method of determination at runtime does not constitute a limitation of this disclosure.

[0077] Optionally, in some complex terrain scenarios, the virtual character may be simultaneously situated within a narrow passage with virtual obstacles on both sides. In this case, both third zones of the second throwing control may be available simultaneously. To prevent sudden changes in lateral throwing direction caused by players crossing zones during swiping, the system can lock a third zone when the player first presses it. This ensures that even if the directional component of the swipe displacement has a value opposite to the preset direction in the computer coordinate system, the lateral throwing direction will remain the direction corresponding to the initially pressed zone as long as the player's touch point is not released and the player does not explicitly switch to the opposite third zone. Furthermore, if the system supports multi-touch and the player's finger simultaneously covers both third zones, the system can select the preset throwing direction corresponding to the dominant third zone as the current lateral throwing direction based on the touch pressure, touch area, or touch point center position. It also provides auxiliary functions for fine-tuning the curvature or adjusting the height of the other side, thereby ensuring the certainty of direction determination and the stability of the interaction logic.

[0078] Optionally, the lateral throwing arc is used to characterize the curvature of the trajectory when a virtual prop is thrown laterally. It is generated based on the sliding distance and is limited by the maximum arc. Optionally, the lateral throwing arc can be an angle value or curvature parameter obtained by transforming the sliding distance through a mapping function. It is used to correct the lateral offset of the initial velocity vector of the virtual prop, so that the throwing trajectory presents a parabolic shape that bends towards the target side. As a specific implementation, the above mapping calculation can adopt a linear mapping relationship. For example, every 2 pixels increase in sliding distance corresponds to an increase of 1 degree in lateral throwing arc. When the sliding distance reaches a cumulative 60 pixels, the corresponding lateral throwing arc is 30 degrees. The value of this preset maximum arc can be dynamically adjusted or statically configured according to the physical simulation parameters of the thrown object, the throwing force setting of the virtual character, and the game balance requirements. The purpose is to reasonably limit the lateral throwing control from both the physical laws and gameplay dimensions, preventing players from throwing objects at large angles when not close to corners, thereby maintaining the realism of the gameplay mechanism and the fairness of competition. It should be noted that the above linear mapping is only an example. In actual implementation, nonlinear mapping, piecewise mapping, or lookup table mapping can also be used. Furthermore, the radian value can be calculated in real time during the sliding process and fed back to the throwing trajectory preview rendering pipeline.

[0079] Optionally, the generation of the lateral throwing arc can also be combined with multi-dimensional touch parameters other than the sliding distance for comprehensive judgment, providing richer control dimensions and finer granular control. For example, the system can determine a basic lateral throwing arc based on the sliding distance, and then apply a gain coefficient or attenuation coefficient to this basic arc based on the duration of the sliding operation, the curvature change of the sliding trajectory, or the magnitude of the touch pressure, thereby obtaining the final lateral throwing arc. In another implementation, the mapping relationship between the sliding distance and the lateral throwing arc can be designed as a two-stage mapping: in the first stage with a smaller sliding distance, a gentler mapping slope is used, facilitating fine-tuning by the player; in the second stage with a larger sliding distance, a steeper mapping slope is used, allowing the player to quickly reach the limit value when the maximum arc is required. It should be understood that regardless of the mapping method used, the final output lateral throwing arc needs to be truncated by a preset maximum arc upper limit to ensure that any sliding input will not produce a physically unreasonable throwing trajectory beyond the design's allowable range.

[0080] Optionally, the lateral throwing arc not only directly affects the horizontal deflection angle of the virtual item, but can also be combined with the physical simulation parameters of the thrown object itself to jointly determine the specific shape of the throwing trajectory in three-dimensional space. When the player holds down the third section and slides, the system calculates the lateral throwing arc based on the sliding distance, and can further combine the weight attributes of the virtual item, the air resistance coefficient, and the preset initial release velocity to dynamically correct or map the lateral throwing arc, making the throwing trajectory more consistent with the preset physical laws within the game world. In addition, the preset maximum arc parameter can be set differently in the game according to different types of virtual items. For example, the preset maximum arc of virtual items that produce an instantaneous area of ​​effect is set to a smaller angle to limit the tactical coverage of their lateral throwing, while virtual items that provide a continuous area effect can allow for a larger lateral throwing arc, thereby providing differentiated tactical positioning and gameplay strategy depth. It should be understood that the above-mentioned arc calculation and prop type association mechanism is intended to enrich strategy choices and make the lateral throwing curve compatible with the gravity influence and flight characteristics of each virtual prop, so as to ensure that different types of virtual props can maintain their original design positioning and balance attributes under the lateral throwing mechanism.

[0081] In an optional implementation, determining the throwing trajectory of the virtual prop in response to a sliding operation on the second throwing control includes: adjusting the throwing height of the virtual prop in response to a sliding operation simultaneously applied to the third and first zones or simultaneously applied to the third and second zones. This allows players to simultaneously adjust the throwing height via composite touch controls when performing a side throw, achieving coordinated control of side throws and high or low throws, effectively enriching the tactical dimensions of throwing and improving operational flexibility in complex scenarios.

[0082] In one specific approach, when a player needs to further adjust the throwing height of a virtual item in side-throw mode, they can simultaneously touch the third and first sections of the second throwing control with their finger, such as the left and upper sections. Upon recognizing this combined touch input, the system accordingly raises the throwing height to the high-throw setting. In this example, the combined touch gesture does not change the already determined side-throw direction, but only corrects the vertical trajectory of the virtual item. Furthermore, if the player simultaneously covers the third and second sections, such as the left and lower sections, the throwing height is lowered to the low-throw setting. It should be noted that during the above combined touch process, the third section always serves as the primary trigger area for the side-throw function, while the combined effect of the first or second section acts as an auxiliary trigger condition for height adjustment. Both work together to quickly switch the throwing height.

[0083] Optionally, the aforementioned composite sliding operation is used to trigger coordinated adjustments to the throwing height by simultaneously covering multiple zones during a lateral throw.

[0084] Optionally, the specific form of this composite sliding operation can be that the player's finger simultaneously contacts the third zone and the first or second zone during actual touch. In a feasible recognition logic, when the touch detection system determines that at least two valid touch points fall into different zones, or determines that the contact area of ​​a single touch point simultaneously crosses the boundary between the third zone and the first (or second) zone, the input can be recognized as a composite sliding operation. It should be noted that the above judgment is not limited to multi-touch hardware solutions. On single-touch devices, the judgment can also be made by detecting the geometric center of the contact area or the location of the largest contact point, combined with its overlap ratio with each zone. One objective of this embodiment is that, through this composite touch method, the player can simultaneously send a command to the system to adjust the throwing height by moving their finger within a small range on the interface without releasing the side-throw control, thereby avoiding the latency and interface jumps caused by step-by-step operations and improving the smoothness of continuous operation.

[0085] Optionally, considering the objective differences in touch accuracy and screen size among different terminal devices, the recognition standard for this composite swipe operation can also be configured to a more fault-tolerant mode. As one possible implementation, the system can first determine the third zone where the primary touch point is located, and then detect whether there is a secondary touch pressure peak within a preset neighborhood, or detect whether the finger contact area extends vertically into the effective sensing range of the first or second zone. If the neighborhood overlap condition is met, it is also considered a composite swipe operation triggered. Furthermore, in another implementation, a time window criterion can be used, allowing players to press the third and first zones sequentially at extremely short time intervals, which the system recognizes as logically simultaneous triggering. This implementation is more user-friendly for players with small screens or single-finger operation habits, reducing reliance on large-area fingertip touch and allowing for compatibility with more operating habits through software-level time tolerance settings.

[0086] Optionally, to avoid ambiguity and conflict between compound swipe operations and simple side-throw swipes, the system can introduce a dominant direction discrimination mechanism in the touch logic. Specifically, upon detecting compound touch input, the system can prioritize mapping the horizontal swipe displacement to the adjustment parameter of the side-throw arc, while using the activation of the additional vertical zone (first or second zone) as the condition for switching the throw height. In other words, even if the player's finger touches a slight vertical shift during the swipe, as long as the horizontal displacement persists, the system maintains real-time updates to the side-throw arc, while the vertical height setting is switched only once upon detecting that an additional zone has been pressed. It should be understood that if the player accidentally touches the opposite height zone during a side-throw swipe, causing both the first and second zones to be identified simultaneously, the system can maintain the default height or use the subsequent trigger as the standard, thereby ensuring the logical stability of the throw trajectory.

[0087] Optionally, the throwing height represents the vertical initial velocity component when the virtual prop is thrown, and is dynamically determined based on the combination of zones triggered by the compound sliding operation. Optionally, the throwing height in this scheme can be configured with at least two discrete levels, corresponding to the high-throw and low-throw states respectively. When the compound sliding operation detects that the additional trigger is the first zone, the system sets the throwing height to the high-throw level. At this time, the virtual prop obtains a larger vertical initial velocity, and its flight trajectory presents a relatively high parabolic shape, which is suitable for crossing high cover or achieving a delayed air explosion at a long distance. When the additional trigger is the second zone, the system sets the throwing height to the low-throw level. At this time, the vertical initial velocity is limited to a lower level, and the virtual prop approaches the target quickly with a nearly straight or low trajectory, which is suitable for scenarios such as passing through narrow windows or door gaps at close range. It should be noted that the above description of high and low throws is only one example. In actual implementation, the throwing height can also be subdivided into more continuous or discrete levels. Its specific value can be dynamically calibrated according to the weight of the virtual prop, the air resistance coefficient, and the physical parameters of the current game level. This disclosure is not intended to limit the quantification method of throwing height.

[0088] Optionally, the throwing height and lateral throwing arc can be treated as independent control variables when determining the final throwing trajectory. One objective of this embodiment is to decouple the vertical height parameter from the horizontal lateral throwing parameter, so that players do not need to worry about unpredictable changes in the vertical parameters while controlling the lateral throwing arc. At the physics simulation level, the client can calculate a base throw elevation angle based on the currently determined throwing height, and then calculate a lateral throwing yaw angle based on the lateral throwing arc. These two angles, along with a preset base initial velocity vector, are then spatially synthesized to obtain the initial velocity vector in three-dimensional space. Furthermore, if game design requirements stipulate that lateral throws cannot be excessively high, the system can also preset a set of constraint rules. For example, if the lateral throwing arc exceeds a specified threshold, the upper limit of the throwing height can be automatically lowered, thereby maintaining tactical physical rationality while ensuring operational freedom.

[0089] In an optional implementation, the method further includes: simulating the throwing trajectory of a virtual item on a graphical user interface in response to a swipe operation; and throwing the virtual item according to the determined throwing trajectory in response to the release of the swipe operation. In this way, by simulating the throwing trajectory in real time during the swipe and executing it immediately upon release, players can intuitively predict the landing point before throwing, effectively reducing the probability of misthrowing, while making the interactive loop of lateral throwing more coherent and natural.

[0090] In one example, when a player presses and holds the third section to the left of the second throwing control and slides it to the left, the terminal renders a real-time preview of a curved, dotted trajectory on the graphical user interface. This preview line dynamically extends based on the side-throw arc and high or low throw height calculated from the current slide displacement. The player observes the preview line to determine if the target area is being targeted. If the player releases their finger, the system immediately responds to this slide-release operation, generating the projectile according to the determined throwing direction, arc, and height, and assigning it a corresponding initial velocity vector. This causes the projectile to fly along the predicted trajectory and continue flying in the scene under the influence of physical laws. Optionally, this simulation display is used to generate the predicted flight path of the virtual prop in real-time on the graphical user interface to provide feedback to the player on the landing trend.

[0091] Optionally, the above simulation can be displayed as one or more connected predicted trajectory lines. These trajectory lines, based on the currently determined throwing direction, side-throw arc, and throwing height, combined with the initial velocity and gravitational acceleration of the projectile, are calculated using the parabolic motion formula to derive sequential trajectory points and rendered in the game scene. These trajectory lines can be presented as dashed lines, semi-transparent materials, or gradient color bands, ensuring they are clearly distinguishable without completely obscuring the background scene. It should be noted that the above simulation is not limited to continuous curves; it can also include discretely arranged landing point marker arrows or breathing light-style path nodes, as long as they convey the projectile's flight trend after release to the player. Furthermore, when the calculation results indicate that the trajectory will first collide with virtual obstacles in the scene, the preview line can either stop at the collision point or extend into a secondary preview segment after the rebound according to the physics rebound rules, thereby helping the player assess the feasibility of using wall rebounds to achieve corner attacks.

[0092] Optionally, considering the varying requirements for interface cleanliness across different game genres, the simulated display, in addition to directly overlaying trajectory lines into the 3D game scene, can also embed a 2D top-down path map in a localized area of ​​the graphical user interface. For example, a small radar-style perspective window can be generated at the corner of the screen, presenting the player's current position, orientation, and predicted trajectory as top-down planar lines, thus preventing the main viewpoint from being obscured by the trajectory lines. Furthermore, this 2D top-down path map can coexist with the 3D trajectory lines, or it can automatically switch display after the player swipes for a preset time threshold, balancing immersion and information completeness. It should be noted that the above description regarding display dimensions is not intended to be limiting; in actual implementation, only the trajectory endpoint marker can be displayed without showing the complete path, reducing the real-time computational overhead on the client side.

[0093] Optionally, to avoid frequent flickering of the trajectory preview or excessive consumption of computing resources due to rapid player swiping, the system can set update intervals and interpolation smoothing strategies for the simulation display. Specifically, the client does not recalculate the entire trajectory every frame, but performs a complete physical simulation every few frames, and performs linear interpolation or Bézier curve smoothing transitions on the trajectory points between adjacent calculations. If the throwing action is interrupted by the player being hit by an enemy, switching weapons, or entering a vehicle during swiping, the system can immediately terminate the rendering of the trajectory preview and maintain the current side-throw state of the throw button until the player releases the touch, or directly reset the button to the normal two-zone mode. It should be understood that the visibility of the trajectory preview can also be combined with scene lighting and weather effects, such as enhancing the luminosity of the trajectory line in night scenes to maintain sufficient visual recognition.

[0094] Optionally, this release operation can be used to trigger the terminal to perform a throw according to a predetermined trajectory, completing the interactive closed loop from parameter adjustment to actual throw.

[0095] Optionally, the release of the aforementioned swipe operation corresponds to the touch end event caused by the player's finger leaving the touchscreen, or it can correspond to the release signal from an input device such as lifting the left mouse button or the rebound of a gamepad trigger button. To prevent premature or late throwing due to accidental touches, the system can set a very small time window or displacement threshold. If the press is held for more than a preset duration and the swipe displacement has already triggered the arc adjustment, the release operation will be recognized as a valid throwing command. Correspondingly, if the player releases the lateral section without a valid swipe, the system can consider it as canceling the throw or defaulting to a throw with the minimum arc, thus taking into account operational error tolerance. It should be noted that if the virtual character moves out of the wall detection range while the player is holding down the lateral section and swiping, there are several strategies for handling the release operation: the throwing command can be canceled immediately the moment the character leaves the wall, or the current lateral throw function can be maintained until release before the player's finger leaves the screen, thus avoiding the unpleasant experience of the player having already adjusted the arc but being forced to interrupt due to movement errors.

[0096] Optionally, the throwing execution is used in response to a slide release, generating a virtual prop in the game scene based on the determined throwing parameters and assigning it an initial parabolic velocity. Optionally, the above throwing execution is not a simple position generation, but requires calculating an initial velocity vector containing forward and lateral components by comprehensively considering the currently determined throwing direction, side-throw arc, throwing height, and the inherent mass and air resistance coefficient of the thrown object. The magnitude of this initial velocity vector can be consistent with a standard forward throw, or it can be nonlinearly attenuated according to the side-throw arc to reflect the force loss of a single-handed side throw at a larger deflection angle. After generating the virtual prop entity, the client physics engine will place it at the player character's hand position or a predetermined throwing point in front of them and apply the initial velocity to make it enter the parabolic motion simulation stage. It should be understood that the above throwing execution can be applied not only to conventional throwable objects such as grenades and smoke grenades, but also to throwable tactical equipment or environmental interactive props, and this disclosure does not limit it in this way. Furthermore, to prevent projectiles from penetrating the player's own collider at the moment of their creation, the system can apply a collision ignore flag to the projectiles for the first few frames, and then resume normal collision detection once the projectiles have traveled a distance exceeding a safe threshold.

[0097] Optionally, considering the importance of latency compensation in network-synchronized shooting games, after the virtual item is generated, the client can immediately perform physics prediction and display the flight trajectory locally, while the server performs authoritative trajectory calculation and hit determination upon receiving the release event message. If there are slight deviations in radian or altitude parameters between the client and server due to network jitter, the server can use time rollback or parameter verification mechanisms to correct them, ensuring consistency in the landing point of the projectile from different players' perspectives. Furthermore, in some implementations, to enhance the impact, camera shake, arm recoil animation, or projectile primer sound effects can be superimposed on the graphical user interface at the moment of throwing, transforming a simple operation confirmation into multi-sensory interactive feedback. It should be noted that whether the virtual item immediately possesses a full collision volume after throwing, or whether it only affects enemies for a short period before passing through friendly forces, can be configured differently depending on the specific game's faction damage rules.

[0098] According to one embodiment of the present disclosure, the virtual throwing interactive device 300, such as Figure 5 As shown, a graphical user interface (GUI) is provided via a terminal device. The GUI displays at least a portion of a game scene, and the game scene includes at least one virtual character. The device may include: A first providing module 301 is used to provide a first throwing operation control in the graphical user interface. The first throwing operation control is configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw and the second partition is used to trigger a low-throw throw. Detection module 302 is used to detect the spatial positional relationship between the virtual character and virtual obstacles in the game scene; The second providing module 303 is used to provide a second throwing operation control in the graphical user interface when the spatial position relationship meets the preset conditions. The second throwing operation control is configured with a first partition, a second partition and at least one third partition, and the third partition is used to trigger a lateral throwing. The throwing module 304 is used to determine the throwing trajectory of the virtual prop in response to a sliding operation applied to the first throwing operation control or the second throwing operation control.

[0099] By dynamically switching control partitions and responding to sliding operations to determine the throwing trajectory, the interaction path for lateral throwing is simplified. This helps reduce the computational load on the terminal during physical bounce detection and trajectory simulation, and reduces additional UI control rendering overhead, thereby improving interaction efficiency and resource utilization.

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

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

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

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

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

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

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

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

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

[0109] 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 throwing 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 at least one virtual character, characterized in that, The method includes: The graphical user interface provides a first throwing operation control, which is configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw and the second partition is used to trigger a low-throw throw. Detect the spatial relationship between the virtual character and virtual obstacles in the game scene; When the spatial relationship meets the preset conditions, a second throwing operation control is provided in the graphical user interface. The second throwing operation control is configured with a first partition, a second partition and at least one third partition. The third partition is used to trigger a lateral throw. The throwing trajectory of the virtual prop is determined in response to a sliding operation applied to the first or second throwing operation control.

2. The method according to claim 1, characterized in that, The detection of the spatial relationship between the virtual character and the virtual obstacle includes: Detect the spatial positional relationship between the virtual character and virtual obstacles within a preset angle range of the current view direction.

3. The method according to claim 2, characterized in that, The spatial relationship satisfies preset conditions, including: The distance between the virtual character and the virtual obstacle is less than or equal to a preset distance threshold.

4. The method according to claim 3, characterized in that, The step of determining the throwing trajectory of the virtual item in response to a sliding operation applied to the first or second throwing control includes: In response to a sliding operation applied to the first or second throwing control, the throwing direction and arc of the virtual prop are determined.

5. The method according to claim 4, characterized in that, The process of determining the throwing trajectory of the virtual item in response to a trigger operation on the second throwing control includes: The sliding displacement relative to the contact point is obtained for the sliding operation acting on the third partition, and the sliding displacement includes the sliding direction and the sliding distance. Based on the sliding direction, the lateral throwing direction of the virtual prop is determined, and the sliding direction is consistent with the preset throwing direction of the third partition; The lateral throwing arc of the virtual prop is determined based on the sliding distance, wherein the lateral throwing arc is less than or equal to a preset maximum arc.

6. The method according to claim 5, characterized in that, The process of determining the throwing trajectory of the virtual prop in response to a sliding operation on the second throwing control includes: In response to a sliding operation that simultaneously applies to the third partition and the first partition or simultaneously applies to the third partition and the second partition, the throwing height of the virtual prop is adjusted.

7. The method according to claim 1, characterized in that, The method further includes: In response to the sliding operation, the throwing trajectory of the virtual prop is simulated on the graphical user interface; In response to the release of the sliding operation, the virtual prop is thrown according to the determined throwing trajectory.

8. An interactive device for virtual throwing, 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 at least one virtual character, characterized in that, The device includes: A first providing module is configured to provide a first throwing operation control in the graphical user interface, the first throwing operation control being configured with a first partition and a second partition, wherein the first partition is used to trigger a high-throw throw and the second partition is used to trigger a low-throw throw. The detection module is used to detect the spatial positional relationship between the virtual character and virtual obstacles in the game scene; The second providing module is used to provide a second throwing operation control in the graphical user interface when the spatial position relationship meets the preset conditions. The second throwing operation control is configured with a first partition, a second partition and at least one third partition, and the third partition is used to trigger a lateral throw. The throwing module is used to determine the throwing trajectory of the virtual prop in response to a sliding operation applied to the first throwing operation control or the second throwing operation control.

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

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

Images