Flyable tool-based interaction method, device, electronic device, and computer program

Abstract

A flyable tool-based interaction method, device, electronic device, and storage medium are disclosed, which belong to the technical field of computers. The method is executed by an electronic device and includes the steps of: (1201) creating a first flyable tool in a virtual scene in response to a virtual skill release operation by a first virtual object, the first flyable tool being associated with the virtual skill and the first virtual object belonging to a first faction; (1202) controlling the first flyable tool to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation; and (1203) controlling the first flyable tool to move along a second flight trajectory when a second flyable tool is detected within a target range of the first flyable tool, the second flyable tool being released by the second virtual object and the second virtual object belonging to a second faction. This application improves resource utilization for flyable tools, enriches flyable tool-based interaction methods, and enhances man-machine interaction efficiency.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to a Chinese patent application filed on December 12, 2022, bearing application number 202211610140.1 and entitled "Interaction method, device, electronic device and storage medium based on flying tools," the entire contents of which are incorporated herein by reference.

[0002] The present application relates to the technical field of computers, and more particularly to an interaction method, device, electronic device and storage medium based on a flyable implement. [Background technology]

[0003] With the development of computer technology and the diversification of terminal functions, MOBA (Multiplayer Online Battle Arena) games are gradually becoming popular. In the virtual scene provided by MOBA games, virtual objects belonging to the same or different teams can cooperate or compete with each other by unlocking virtual skills. Summary of the Invention [Problem to be solved by the invention]

[0004] The embodiments of the present application provide an interaction method, device, electronic device and storage medium based on a flying tool. [Means for solving the problem]

[0005] According to one aspect, there is provided a flyable tool based interaction method, said method comprising: creating a first flyable tool in the virtual scene in response to a release operation (also called a "cast operation" or "activation operation") of a virtual skill by a first virtual object, the first flyable tool being associated with the virtual skill and the first virtual object belonging to a first camp; controlling the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation; and if a second flyable implement is detected within a target range of the first flyable implement, controlling the first flyable implement to move along a second flight trajectory, wherein the second flyable implement is released by a second virtual object, the second virtual object belonging to a second camp, and the second flight trajectory is different from the first flight trajectory.

[0006] According to one aspect, there is provided a flyable tool based interaction device, said device comprising: a creation module for creating a first flyable tool in the virtual scene in response to a release of a virtual skill by a first virtual object, the first flyable tool being associated with the virtual skill and the first virtual object belonging to a first faction; a first control module for controlling the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation; and a second control module for controlling the first flyable implement to move along a second flight trajectory if a second flyable implement is detected within a target range of the first flyable implement, the second flyable implement being released by a second virtual object, the second virtual object belonging to a second faction, and the second flight trajectory being different from the first flight trajectory.

[0007] According to one aspect, there is provided an electronic device including one or more processors and one or more memories, wherein the one or more memories store at least one computer program, which is loaded and executed by the one or more processors to implement the above-described flyable tool-based interaction method.

[0008] According to one aspect, a computer-readable storage medium is provided, having stored thereon at least one computer program, the at least one computer program being loaded and executed by a processor to implement the above-described flyable implement-based interaction method.

[0009] According to one aspect, there is provided a computer program product, the computer program product including one or more computer programs stored on a computer-readable storage medium, wherein one or more processors of an electronic device can read the one or more computer programs from the computer-readable storage medium, and the one or more processors can execute the one or more computer programs to cause the electronic device to perform the above-described flyable implement-based interaction method.

[0010] The beneficial effects brought about by the technical solutions provided by the embodiments of the present application include at least the following: When a second flyable tool is detected within the target range of the first flyable tool, the first flyable tool is controlled to switch from the first flight trajectory to the second flight trajectory because the first flyable tool and the second flyable tool are in different camps. This allows the flight trajectory of the first flyable tool to be varied as the game progresses, thereby increasing the tool resource utilization rate for the first flyable tool, enriching the interaction methods based on the flyable tools, and improving the efficiency of man-machine interaction. [Brief explanation of the drawings]

[0011] [Figure 1] 1 illustrates a typical virtual world of a MOBA game provided by an embodiment of the present application. [Figure 2] 1 is a schematic diagram of a virtual world observed from the perspective of the Blue Team, according to an embodiment of the present application; [Figure 3] 1 is a schematic diagram of a virtual world observed from the perspective of a red team, according to an embodiment of the present application. [Figure 4] FIG. 1 is a schematic diagram of a terminal displaying a user interface provided by an embodiment of the present application; [Figure 5] FIG. 1 is a schematic diagram of a terminal displaying a user interface provided by an embodiment of the present application; [Figure 6] 1 is a schematic diagram of a virtual world provided by an embodiment of the present application. [Figure 7] 1 is a schematic diagram of a virtual world provided by an embodiment of the present application. [Figure 8] 1 is a schematic diagram of a mirrored virtual world of another typical MOBA game provided by an embodiment of the present application. [Figure 9] 1 is a schematic diagram of a mirrored virtual world of another typical MOBA game provided by an embodiment of the present application. [Figure 10] 1 is a schematic diagram of a mirrored virtual world of another typical MOBA game provided by an embodiment of the present application. [Figure 11] 1 is a schematic diagram of an implementation environment of an interaction method based on a flyable tool provided by an embodiment of the present application; [Figure 12] 1 is a flowchart of an interaction method based on a flyable tool provided by an embodiment of the present application; [Figure 13] 1 is a schematic diagram of a ray trajectory of a single first flyable implement provided by an embodiment of the present application; FIG. [Figure 14] 1 is a schematic diagram of ray trajectories of a plurality of first flyable implements provided by an embodiment of the present application; FIG. [Figure 15] 1 is a schematic diagram of a circular trajectory of a single first flyable implement provided by an embodiment of the present application; FIG. [Figure 16] 1 is a schematic diagram of a circular trajectory of a plurality of first flyable implements provided by an embodiment of the present application; [Figure 17] 1 is a flowchart of an interaction method based on a flyable tool provided by an embodiment of the present application; [Figure 18] FIG. 1 is a diagram illustrating the principle of a collision detection method provided by an embodiment of the present application. [Figure 19] FIG. 2 is a diagram illustrating the selection principle of a second flying tool provided by an embodiment of the present application. [Figure 20] FIG. 1 is a schematic diagram of a blueprint tool provided by an embodiment of the present application. [Figure 21] 1 is a principle schematic diagram of an interaction method based on a flyable tool provided by an embodiment of the present application; FIG. [Figure 22] 1 is a structural schematic diagram of an interaction device based on a flying tool provided by an embodiment of the present application; [Figure 23] 1 is a structural schematic diagram of a terminal provided by an embodiment of the present application; [Figure 24] 1 is a structural schematic diagram of an electronic device provided by an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0012] In order to make the objectives, technical solutions and advantages of the present application clearer, the following describes the embodiments of the present application in more detail in conjunction with the drawings.

[0013] It should be understood that the terms "first," "second," and the like used in this application are used to distinguish between identical or similar items that have essentially the same actions and functions, and that there is no logical or chronological dependency between "first," "second," and "nth," and that there are no limitations on the number or order of execution.

[0014] As used herein, the term "at least one" refers to one or more, and the term "plurality" refers to two or more, for example, a plurality of flyable implements means two or more flyable implements.

[0015] In this application, the phrase "comprising at least one of A or B" refers to a situation including only A, a situation including only B, and a situation including both A and B.

[0016] When user-related information (including, but not limited to, user device information, personal information, behavioral information, etc.), data (including, but not limited to, data for analysis, data stored, data displayed, etc.), and signals related to the present application are applied to specific products or technologies in the manners of the embodiments of the present application, they must be permitted, agreed to, or authorized by the user or fully authorized by the relevant parties, and the collection, use, and processing of related information, data, and signals must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, any user operations or commands related to the present application are obtained under fully authorized circumstances.

[0017] In the related art, a certain type of virtual skill exists, and after a virtual object releases this type of virtual skill, a flying tool is created in the virtual scene, which moves according to a preset flight trajectory. Because the flight trajectory of the flying tool is fixed and the validity period is limited, the tool resource utilization rate of the flying tool is low, the interaction mode based on the flying tool is single, and the human-machine interaction efficiency is low. In the embodiments of the present application, a flying tool-based interaction method is provided, which can increase the tool resource utilization rate for the first flying tool, enrich the interaction mode based on the flying tool, and improve the human-machine interaction efficiency. For details, see the following description.

[0018] Virtual scene: A virtual scene displayed (or provided) when an application program is executed on a terminal. The virtual scene may be a simulated environment of the real world, a semi-simulated, semi-fictional virtual environment, or a purely fictional virtual environment. The virtual scene may be any one of a 2D virtual scene, a 2.5D virtual scene, and a 3D virtual scene, and the embodiments of the present application do not limit the dimensions of the virtual scene. For example, the virtual scene may include sky, land, ocean, etc., and the land may include environmental elements such as deserts and cities, and a user can control virtual objects to move in the virtual scene. Optionally, the virtual scene may further be used for a virtual scene battle between at least two virtual objects, and the virtual scene includes virtual resources available to the at least two virtual objects. Optionally, the virtual scene includes two symmetrical regions, with virtual objects belonging to two different camps each occupying one region, and the victory goal is to destroy a target building / base / outpost / nexus located at the back of the opponent's region, where the symmetrical regions are, for example, the lower left corner region and the upper right corner region, or, for example, the left middle region and the right middle region, etc.

[0019] Virtual object: refers to a movable object in a virtual scene. The movable object may be a virtual person, a virtual animal, a virtual elf, a cartoon character, etc., such as a person, an animal, a plant, an oil bucket, a wall, a stone, etc., displayed in the virtual scene. The virtual object may be a virtual avatar representing a virtual user in the virtual scene. The virtual scene may include multiple virtual objects, each of which has its own shape and volume in the virtual scene and occupies a portion of the space of the virtual scene. Optionally, if the virtual scene is a 3D virtual scene, the virtual object may be a 3D solid model, which may be a 3D character constructed based on 3D human skeleton technology. The same virtual object can exhibit different appearances by wearing different skins. In some embodiments, the virtual object may be realized using a 2.5D or 2D model, although the embodiments of the present application are not limited thereto.

[0020] The virtual object may be a player character controlled by an operation on a client, or a non-player character (NPC) set in an interaction in a virtual scene. Optionally, the virtual object may be a virtual person competing in a virtual scene. Optionally, the number of virtual objects participating in an interaction in the virtual scene may be preset, or may be dynamically determined depending on the number of clients participating in the interaction.

[0021] Virtual skill: Refers to a unique interaction skill that can be unlocked by a virtual object in a virtual environment. Typically, different virtual objects are bound to different dedicated virtual skills, but there are also common virtual skills that different virtual objects can share. The user can select which common virtual skill to equip in the current match. Already equipped common virtual skills cannot be changed during the match, and there is a limit to the number of common virtual skills that can be equipped in a match. Skill types of virtual skills may include attack skills, defense skills, healing skills, support skills, harvesting skills, etc. Typically, after a virtual object unlocks a virtual skill, the virtual skill has a skill cooldown (CD). During the skill cooldown period, the user cannot unlock the virtual skill again. After the skill cooldown expires, the virtual skill can be restored to a unlockable state. Different virtual skills may have the same or different skill CD lengths. Not all virtual skills have a skill CD; a virtual skill without a skill CD can be considered to have a skill CD of 0.

[0022] Flying tool: refers to a flying virtual tool that is generated, summoned, released, or created by a virtual skill after a virtual object releases a virtual skill. Flying tools can also be considered summons of virtual skills or summons of virtual objects. Typically, flying tools generated by virtual skills move along a preset flight trajectory, for example, moving along a ray trajectory from the virtual object toward the joystick until the flying tool reaches its effective period (or reaches its flight distance, or collides with a virtual object of another side and causes a certain virtual damage value).

[0023] MOBA (Multiplayer Online Battle Arena) games: A multiplayer online battle arena game is a game in which a virtual scene is provided with several bases, and users positioned on different sides compete in the virtual scene, controlling virtual objects to capture bases or destroy the bases of the opposing side. For example, a MOBA game can divide users into at least two sides, with different teams belonging to each of the at least two sides occupying their own map areas and competing to achieve certain victory conditions. The victory conditions include, but are not limited to, at least one of capturing a base or destroying the opposing side's base, defeating the opposing side's virtual object, ensuring one's own survival within a specified scene and time period, capturing certain resources, and exceeding the opponent's interaction score within a specified time period. For example, a MOBA game can divide users into two sides, and user-controlled virtual objects are distributed throughout the virtual scene and compete against each other to destroy or capture a target building / base / base / nexus deep in the opponent's territory.

[0024] Optionally, each team may include one or more virtual objects, for example, one, two, three, or five. According to the number of virtual objects in each team participating in the game match, the tactical competition may be divided into 1V1 competition, 2V2 competition, 3V3 competition, 5V5 competition, etc., where 1V1 refers to "one against one," and no further elaboration is needed here.

[0025] Optionally, MOBA games are played in units of matches (also called rounds), and the scene map selected for each match may be the same or different. The duration of each MOBA game is the time from when the game starts to when any team or faction achieves the victory condition.

[0026] In a MOBA game, a user can select different virtual objects to be primarily controlled in different matches, and the primary virtual object selected in each match cannot be changed in that match, but a different primary virtual object can be selected in another match. After selecting a primary virtual object, a user can control the primary virtual object to release virtual skills in the virtual scene, thereby achieving the effect of interacting with other virtual objects in the opposing camp.

[0027] Below, we will introduce two typical MOBA games.

[0028] It is a typical MOBA game of the first kind.

[0029] Figure 1 shows a two-dimensional map of the virtual world of a typical MOBA game. In such a typical MOBA game, virtual characters are divided into two camps, the red team and the blue team, with each camp having five virtual characters, for a total of ten virtual characters who play a MOBA game together.

[0030] As shown in Figure 1, the virtual world map is square and divided into several parts as follows: at both ends of one diagonal of the square, there are two camp bases (nexuses), namely, the blue team base 1001 and the red team base 1002; the three advance lanes connecting the blue team base 1001 and the red team base 1002 are the top lane 1003, the mid lane 1004, and the bot lane 1005, respectively; and the shared areas are the river 1006 and the jungle 1007.

[0031] The virtual characters of the two teams are born at their respective base locations, and the five virtual characters of the same team begin to advance toward the opponent along three advance directions, and the game is won by destroying the opponent's base. The blue team team is born at blue team base 1001, and the red team team is born at red team base 1002. The virtual characters of both teams observe the virtual world from a viewpoint where their own team's base is located in the lower left corner of the observation viewpoint. That is, the blue team's virtual characters observe the virtual world from a first viewpoint 1008, and the red team's virtual characters observe the virtual world from a second viewpoint 1009. From each viewpoint, the three advance directions are, from left to right, the top lane, mid lane, and bot lane, respectively. For example, as shown in FIG. 2, the virtual world is observed from a first viewpoint 1008 of the Blue Team's virtual character, with the Blue Team's base 1001 located in the lower left corner of the virtual world screen, and as shown in FIG. 3, the virtual world is observed from a second viewpoint 1009 of the Red Team's virtual character, with the Red Team's base 1002 located in the lower left corner of the virtual world screen.

[0032] By setting the viewpoints of the two camps in this way, regardless of whether the virtual character controlled by the user belongs to the red team camp or the blue team camp, the opposing camp's base is always located in the upper right corner of the virtual world screen, and the virtual character's advance direction is always toward the upper right of the virtual world screen, which is helpful for the user to operate and control the virtual character. However, this setting also has a problem. Namely, if the blue team's bot lane is the red team's top lane and both the blue team's virtual characters and the red team's virtual characters are located at the boundary (river) between the blue team's bot lane and the red team's top lane, the user interface viewed by the blue team user on their device will be as shown in FIG. 4. Although some of the virtual world screen will be blocked by UI (User Interface) controls 1010, the dangerous river 1006 area (where the red team's virtual character, e.g., an assassin, may suddenly begin an advance from the river 1006) will not be blocked, and therefore the blue team user will have a wide field of view. As shown in Figure 5, the user interface viewed by the red team on their terminal also has some of the virtual world screen obscured by UI controls 1010, and the dangerous river 1006 area is obscured by the UI controls, affecting the field of view of the red team's users. This makes it difficult for the red team's users to observe the river 1006 area, making it easy for them to be defeated by the blue team's assassins.

[0033] Therefore, bot lane 1005 is safer than top lane 1003.

[0034] The five virtual characters of the same camp are usually five different types of virtual characters, and illustratively, the types of virtual characters may be as follows: Warrior: Has many hit points, high defense, high attack power, short attack range, flexible movement, and usually has a certain displacement skill, which allows it to resist or inflict injury to an opponent to a certain extent. Displacement skills are skills that can increase the virtual character's movement speed, jump a certain distance in a certain direction, or teleport from one point to another. Magician: Very low hit points, very low defense, very high attack power and magic damage, long attack range, inflexible movement, easy to kill, so usually attack opponents with the protection of a warrior or tank / assistant. Tank / Assistant: Very high hit points, very high defense, very low attack power, short attack range, usually suited to being at the front of the team, resisting injury for teammates and protecting other teammates. Shooter: Similar to the Magician, but the difference is that the Shooter has very high physical damage, outputs it continuously, and is suitable for attacking towers and bases. Assassin: Low hit points, low defense, high attack power, short attack range, very flexible movement, usually has many displacement skills, suitable for charging at the opposing magician or shooter, and has the ability to instantly defeat the opposing magician or shooter.

[0035] Different types of virtual characters have their own characteristics, and combine their advantages and disadvantages in the perspectives of the top lane and bot lane. Different types of virtual characters usually start their attack on the opponent in a fixed direction. Usually, shooters (and tanks / assistants) start their attack on the opponent from the safe bot lane 1005, magicians start their attack on the opponent from the mid lane 1004, warriors with a certain displacement advantage start their attack on the opponent from the dangerous top lane 1003, and assassins mainly operate in the jungle 1007, waiting for opportunities to support teammates in the top lane, mid lane 1004, or bot lane 1005.

[0036] In this way, virtual characters will be matched up against opposing virtual characters of a different type, such as a shooter from the blue team matched up against a warrior from the red team, and a warrior from the blue team matched up against a shooter from the red team, which affects the fairness of the game and the user's experience. For example, as shown in FIG. 6 , the No. 1 shooter 1011 of the blue team advances from the bot lane 1005 of the blue team to the red team, the No. 1 warrior 1012 of the blue team advances from the top lane 1003 of the blue team to the red team, the No. 2 shooter 1013 of the red team begins to advance from the bot lane 1005 of the red team to the blue team, and the No. 2 warrior 1014 of the red team begins to advance from the top lane 1003 of the red team to the blue team. That is, the No. 1 shooter 1011 will face the No. 2 warrior 1014, and the No. 1 warrior 1012 will face the No. 2 shooter 1013.

[0037] To make the game fairer, a more reasonable matchup format would be as shown in FIG. 7, where the Blue team's No. 1 shooter 1011 plays against the Red team's No. 2 shooter 1013, and the Blue team's No. 1 warrior 1012 plays against the Red team's No. 2 warrior 1014. To achieve this matchup format, it is necessary to solve the problem of how to make the Blue team's bot lane and the Red team's bot lane the same lane. That is, by swapping the top lane and bot lane of one of the Blue team or the Red team, the original bot lane becomes the top lane, and the original top lane becomes the bot lane. For example, the Red team's top lane and bot lane are moved to the positions of top lane 1003 and bot lane 1005, as shown in FIG. 7. The Blue team's bot lane 1005 is similarly the Red team's bot lane 1005, and the Blue team's top lane 1003 is similarly the Red team's top lane 1003.

[0038] The second type of typical MOBA game implements this more rational battle format.

[0039] It is a typical MOBA game of the second kind.

[0040] The second type of typical MOBA game mode is similar to the first type of typical MOBA game in terms of gameplay: it also has a square virtual world, the first and second camps' bases are also located diagonally across the square, and the five virtual characters from each camp each launch attacks on the opponent along one of three directions. The difference is that the first camp's bot lane is also the second camp's bot lane, and the first camp's top lane is also the second camp's top lane. The second type of typical MOBA game achieves this more streamlined battle format in the following way:

[0041] The game game has a first virtual world and a second virtual world that is a horizontal mirror image of the first virtual world. As shown in Figure 8, the game game has a first virtual world 1101 and a second virtual world 1103 that is symmetrical to the first virtual world 1101 with respect to a horizontal plane 1102, i.e., the second virtual world is a mirror image of the first virtual world.

[0042] If the direction perpendicular to the ground plane of the first virtual world and pointing skyward is the positive half-axis direction of the y-axis 1104, the virtual world seen by the user controlling the virtual character of the first camp is the first virtual world observed in a space where the viewpoint is located on the positive half-axis of the y-axis. As shown in FIG. 9, this is the first virtual world observed by the user controlling the virtual character of the first camp. The virtual world seen by the user controlling the virtual character of the second camp is the second virtual world observed in a space where the viewpoint is located on the negative half-axis of the y-axis. As shown in FIG. 10, this is the second virtual world observed by the user controlling the virtual character of the second camp. The first virtual world 1101 and the second virtual world 1103 are reversed worlds. This method can be used to swap the top lane and bot lane of the second camp. Similarly, the bot lane seen by the user controlling the virtual character of the second camp is the bot lane seen by the user controlling the virtual character of the first camp.

[0043] A typical second type of MOBA game presents two mirror-image virtual worlds to users from two camps. Users from the first camp observe the first virtual world from the perspective of the positive half of the y-axis and control their virtual characters to act in the first virtual world. Users from the second camp observe the second virtual world from the perspective of the negative half of the y-axis and control their virtual characters to act in the second virtual world. Because the first and second virtual worlds are completely opposite worlds, the server must set up two sets of calculation logic for the first and second virtual worlds, respectively. The first calculation logic is used to calculate activity information of the first camp's virtual characters in the first virtual world, such as movement position and skill release direction, and the second calculation logic is used to calculate activity information of the second camp's virtual characters in the second virtual world. The calculation results of one virtual world must then be displayed in the other virtual world.

[0044] The system architecture according to the present invention will be introduced below.

[0045] 11 is a schematic diagram of an implementation environment of an interaction method based on a flyable tool provided in an embodiment of the present application. Referring to FIG. 11, the implementation environment includes a first terminal 120, a server 140, and a second terminal 160.

[0046] An application program supporting a virtual scene is installed and executed on the first terminal 120. The application program may be any one of an MOBA game, a massively multiplayer online role-playing game (MMORPG), a first-person shooter game (FPS), a third-person shooter game, a virtual reality application program, a 3D map program, or a multiplayer survival game. The first terminal 120 may be used by a first user. The first user uses the first terminal 120 to manipulate a first virtual object located in the virtual scene to perform an action, including, but not limited to, adjusting body posture, crawling, walking, running, cycling, jumping, driving, picking up, shooting, attacking, throwing, and unleashing a virtual skill. Exemplarily, the first virtual object is a first virtual person, such as a simulated human character or an animated human character.

[0047] The server 140 may include at least one of a single server, multiple servers, a cloud computing platform, and a virtualization center. The server 140 provides back-end services for application programs supporting virtual scenes. Optionally, the server 140 may perform primary computing tasks, and the first terminal 120 and the second terminal 160 may perform secondary computing tasks. Alternatively, the server 140 may perform secondary computing tasks, and the first terminal 120 and the second terminal 160 may perform primary computing tasks. Alternatively, a distributed computing architecture may be adopted among the server 140, the first terminal 120, and the second terminal 160 to perform collaborative computing.

[0048] An application program supporting a virtual scene is installed and executed on the second terminal 160. The application program may be any one of an MOBA game, an MMORPG game, an FPS game, a third-person shooter game, a virtual reality application program, a 3D map program, or a multiplayer survival game. The second terminal 160 may be used by a second user. The second user uses the second terminal 160 to manipulate a second virtual object located in the virtual scene to perform an action, including, but not limited to, adjusting body posture, crawling, walking, running, cycling, jumping, driving, picking up, shooting, attacking, throwing, and unleashing a virtual skill. Exemplarily, the second virtual object is a second virtual person, such as a simulated human character or an animated human character.

[0049] The first terminal 120 and the second terminal 160 can be directly or indirectly connected to the server 140 via wired or wireless communication, and the embodiment of the present application does not limit the connection method here.

[0050] In some embodiments, a first virtual object controlled by the first terminal 120 is in the same virtual scene as a second virtual object controlled by the second terminal 160, in which case the first virtual object can interact with the second virtual object in the virtual scene.

[0051] In some embodiments, the first virtual object and the second virtual object may be in a competitive relationship. For example, the first virtual object and the second virtual object may belong to different teams or camps. The competitive virtual objects may compete by releasing virtual skills to each other. For example, the first virtual object may release an attack skill on the second virtual object. In subsequent embodiments, an example in which the first virtual object and the second virtual object are in a competitive relationship will be described.

[0052] In some other embodiments, the first virtual object and the second virtual object may further be in a teammate relationship, for example, the first virtual object and the second virtual object may belong to the same team or organization, and may have a friendship relationship or temporary communication permissions, and in such cases, the first virtual object may release an auxiliary skill to the second virtual object.

[0053] The server 140 may be an independent physical server, a server cluster or a distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0054] The first terminal 120 or the second terminal 160 may be, but is not limited to, a smartphone, a smart PC, a portable game device, a tablet computer, a laptop, a desktop computer, a smart speaker, a smart watch, an MP3 (Moving Picture Experts Group Audio Layer III) player, an MP4 (Moving Picture Experts Group Audio Layer IV) player, an e-book reader, etc.

[0055] The application program installed on the first terminal 120 and the second terminal 160 may be the same, or the application programs installed on the two terminals may be the same type of application program on different operating system platforms. The first terminal 120 may refer to one of multiple terminals, and the second terminal 160 may refer to one of multiple terminals, and this embodiment will be described using only the first terminal 120 and the second terminal 160 as examples. The device types of the first terminal 120 and the second terminal 160 may be the same or different.

[0056] As will be appreciated by those skilled in the art, the number of terminals may be greater or less. For example, there may be only one terminal, or there may be tens or hundreds of terminals, or even more. The embodiments of the present application do not limit the number and device types of terminals.

[0057] 12 is a flowchart of an interaction method based on a flying tool according to an embodiment of the present application. Referring to FIG. 12, the embodiment is performed by an electronic device, and the electronic device is a terminal, and the embodiment includes steps 1201 to 1203.

[0058] 1201. In response to a release operation of a virtual skill by a first virtual object, the terminal creates a first flyable tool in the virtual scene, the first flyable tool is associated with the virtual skill, and the first virtual object belongs to a first camp.

[0059] In the embodiments of the present application, a first virtual object refers to a virtual object that is primarily operated by a user using a terminal, and the camp to which the first virtual object belongs is referred to as a first camp. For example, in a MOBA game, two camps are involved: a first camp to which the first virtual object belongs, and a second camp to which the second virtual object belongs. The first camp and the second camp are different camps, and for example, the first camp and the second camp are in a competitive relationship with each other.

[0060] The virtual skill in the embodiments of the present application refers to a virtual skill that can summon any flying tool that can be released by the first virtual object, that is, the virtual skill may be a virtual skill bound to or dedicated to the first virtual object, or a virtual skill common to all virtual objects, and the virtual skill is not specifically limited here.

[0061] The flying tool in the embodiments of the present application refers to a flying virtual tool in a virtual scene that is generated, summoned, released, or created after a first virtual object releases a virtual skill, for example, the flying tool is a virtual skill's projectile, throwable object, summoned object, flying pet, flying vehicle, etc. The first flying tool is associated with the virtual skill, and the virtual skill can be understood as being used to generate, summon, release, or create the first flying tool.

[0062] In some embodiments, a user launches a game application on a terminal and performs a game start operation in the game application to start a game match. Subsequently, the terminal loads and displays a virtual scene of the game match in the game application, and displays a first virtual object that is primarily operated by the terminal in the virtual scene. Optionally, before starting the game, the user can select a first virtual object to appear in the current game match from a plurality of selectable virtual objects in the game start interface. For example, the user can select a main operation hero that satisfies the positioning of the current lane from a hero pool already owned by the user as the first virtual object. Alternatively, if the user does not make a selection, the system can allocate the first virtual object for the current game match to the user. The allocation method can be random allocation, preferentially selecting a hero that appears most frequently in an account bound to the user, or selecting a hero that has the highest operation score in an account bound to the user, etc., and the embodiments of the present application are not specifically limited thereto.

[0063] In some embodiments, after completing the selection or allocation for the first virtual object, the first virtual object will automatically have or be equipped with the dedicated virtual skills in the game match; at the same time, in the game start interface, the user can further select a specified number of common virtual skills to also have the common virtual skills in this game match, so that the first virtual object can release the dedicated virtual skills and the common virtual skills, and the specified number is determined by the business logic of the game application and is not limited here.

[0064] In some embodiments, after the loading of the virtual scene is completed, the user can control the first virtual object to interact in the virtual scene, and if the first virtual object has a virtual skill that can selectively generate, summon, release or create a flying tool, the terminal creates a first flying tool bound to the virtual skill in the virtual scene when it detects the user's release operation on the virtual skill, and the first flying tool means the flying tool created by the first virtual object through the virtual skill.

[0065] In some embodiments, the release operation for the above virtual skill includes, but is not limited to, a click operation, a touch operation, a press operation, a drag-and-drop operation, a swipe operation, etc. on the skill control of the virtual skill, and the user can further control the release direction of the virtual skill by a joystick control, and the embodiments of the present application do not specifically limit the embodiment of the release operation.

[0066] In some embodiments, after detecting a release operation for a virtual skill, the device determines whether the virtual skill can summon a flying tool. If the virtual skill can summon a flying tool, the device queries a cache using a skill identification (ID) of the virtual skill as an index to obtain a tool resource stored in association with the skill ID. The tool resource is used to display a first flying tool. The device then renders the tool resource using a rendering engine to display the first flying tool in the virtual scene. Optionally, skill configuration information is cached in the device, the skill configuration information including an association relationship between the skill identifier and the tool resource identifier, where the association relationship between the skill identifier and the tool identifier indicates that the virtual skill indicated by the skill identifier is associated with the virtual tool indicated by the tool resource identifier. Thus, the device determines a tool resource for the first flying tool associated with the virtual skill according to the skill configuration information, and renders the tool resource to obtain the first flying tool.

[0067] 1202, the terminal controls the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation.

[0068] In some embodiments, the terminal can determine the release direction of the virtual skill based on the release operation on the virtual skill performed by the user in step 1201, and then generate a first flight trajectory according to the release direction of the virtual skill.

[0069] Alternatively, the release direction of the virtual skill may be a direction specified by the user via the joystick control. For example, the user's finger presses the joystick control to select the release direction, and then performs a release operation on the virtual skill. In this way, the release direction determined based on the joystick control can be directly obtained, and the release direction may be the direction in which the center point of the joystick control on the terminal screen faces the touch point of the user's finger. In this way, the user can press the skill control with one hand to trigger the release operation, and use the other hand to control the joystick control to fine-tune the release direction, providing a high degree of freedom in operation.

[0070] Optionally, the release direction of the virtual skill may also be a direction specified by the user via the skill control. For example, the user can press the skill control of the virtual skill with his / her finger and then swipe in the release direction. After the user releases his / her finger (i.e., after the swipe operation is completed), the virtual skill is triggered and released, and the release direction may be the swipe direction of the swipe operation. In this way, the user can directly operate the skill control with one hand and simultaneously select the release direction to trigger the release operation, which simplifies the user's man-machine interaction flow.

[0071] Optionally, the release direction of the virtual skill may further be a release direction automatically determined by the terminal after the user selects a release target, for example, after the user locks the interaction focus on a certain release target, any virtual skill triggered by the user is automatically locked to the release target, and the release target may be a virtual object of the opponent's camp, or some virtual object that the player cannot control, such as a field monster, a minion, a base, etc. For example, the terminal automatically sets the direction from the first virtual object toward the release target in the current frame as the release direction of the virtual skill.

[0072] In some embodiments, when the virtual skill releases only a single first flyable tool, the first flight trajectory may be a single ray trajectory starting from the current position of the first virtual object and pointing in the direction of release of the virtual skill, so that the terminal can control the first flyable tool to move along the ray trajectory.

[0073] 13, which is a schematic diagram of a ray trajectory of a single first flying tool provided by an embodiment of the present application, in which a first virtual object 1301 and a second virtual object 1302 are displayed in a virtual scene 1300, the first virtual object 1301 belongs to a first camp, and the second virtual object 1302 belongs to a second camp, and the first camp and the second camp are in a competitive relationship with each other. In one example, the first virtual object 1301 is equipped with dedicated virtual skills 1311 to 1313 and common virtual skills 1314 to 1315. Optionally, when the user controls the first virtual object 1301 to release the virtual skill 1311, a first flyable implement 1321 is created in the virtual scene 1300 summoned by the virtual skill 1311, and the first flyable implement 1321 moves along a single ray trajectory 1322, which is a single ray from the first virtual object 1301 to the second virtual object 1302, and the ray trajectory 1322 is an exemplary illustration of the first flight trajectory.

[0074] In some other embodiments, when the virtual skill can release multiple first flying tools, the first flight trajectory may be multiple ray trajectories starting from the current position of the first virtual object and pointing in the direction of the release of the virtual skill, and the angle difference between the multiple ray trajectories may be the same or different. For example, the ray trajectory of the central first flying tool among the multiple first flying tools is set to overlap with the release direction, and the ray trajectories of the remaining first flying tools all maintain a certain angle difference between them, thereby creating a scattering effect similar to that of the multiple first flying tools.

[0075] 14 is a schematic diagram of ray trajectories of multiple first flying tools provided by an embodiment of the present application. A first virtual object 1401 and a second virtual object 1402 are displayed in a virtual scene 1400. The first virtual object 1401 belongs to a first team, and the second virtual object 1402 belongs to a second team, and the first and second teams are in a competitive relationship. In one example, the first virtual object 1401 is equipped with dedicated virtual skills 1411-1413 and common virtual skills 1414-1415. Optionally, when a user controls the first virtual object 1401 to release the virtual skill 1411, multiple first flying tools 1421 summoned by the virtual skill 1411 are created in the virtual scene 1400. Here, an example in which five first flying tools 1421 are summoned is described. Each first flyable implement 1421 moves along a single ray trajectory 1422, which is also an exemplary illustration of a first flight trajectory.

[0076] 1203, when a second flyable tool is detected within the target range of the first flyable tool, the terminal controls the first flyable tool to move along a second flight trajectory, and the second flyable tool is released by a second virtual object, and the second virtual object belongs to a second camp.

[0077] In some embodiments, the terminal may perform collision detection on the first flyable tool during the process of the first flyable tool moving along the first flight trajectory, i.e., detect whether a second flyable tool exists within the target range of the first flyable tool, where the second flyable tool is a flyable tool released by a second virtual object of the second faction. In this way, when the second flyable tool is detected within the target range of the first flyable tool, the terminal controls the first flyable tool to perform a flight trajectory transformation, for example, to generate a new second flight trajectory for the first flyable tool and control the first flyable tool to move along the second flight trajectory, where the second flight trajectory is different from the first flight trajectory. Note that when a flyable tool released by another virtual object of the first faction is detected within the target range of the first flyable tool, the terminal does not trigger the flight trajectory transformation because both of these flyable tools belong to the first faction.

[0078] In some embodiments, the target range of a first flyable tool refers to a range in a three-dimensional virtual scene where the distance to the first flyable tool is equal to or less than a predetermined distance, for example, the target range is a spherical region with the first flyable tool as its center and a predetermined distance as its radius, i.e., if the distance between a second flyable tool and the first flyable tool is equal to or less than the predetermined distance, the second flyable tool is considered to be detected within the target range of the first flyable tool. In some other embodiments, the target range refers to a range that is located in the same horizontal plane as the first flyable tool and is a distance from the first flyable tool that is equal to or less than a predetermined distance, for example, the target range is a circular area in the horizontal plane where the first flyable tool is located, with the first flyable tool as its center and a radius of a predetermined distance, i.e., a second flyable tool is deemed to be detected within the target range of the first flyable tool if the second flyable tool is located in the same horizontal plane as the first flyable tool and is a distance from the first flyable tool that is equal to or less than a predetermined distance, or the target range of the first flyable tool refers to a position occupied by the first flyable tool, i.e., a second flyable tool is deemed to be detected within the target range of the first flyable tool if there is an overlap between the position occupied by the second flyable tool and the position occupied by the first flyable tool.

[0079] In some embodiments, when the virtual skill releases only a single first flyable implement, the second flight trajectory may be a circular trajectory surrounding the first virtual object, for example, the second flight trajectory is a circular trajectory with the first virtual object as its center. In this way, after the terminal detects that the second flyable implement exists within the target range of the first flyable implement, it controls the first flyable implement to move along the second flight trajectory, i.e., after the first flyable implement collides with the second flyable implement, the first flyable implement switches from originally moving along a projectile trajectory to moving around the first virtual object along a circular trajectory.

[0080] As shown in FIG. 15, FIG. 15 is a schematic diagram of a circular trajectory of a single first flying tool provided by an embodiment of the present application. The user shown in FIG. 13 controls a first virtual object 1301 to release a virtual skill 1311, thereby summoning a first flying tool 1321 in the virtual scene 1300. During the process of the first flying tool 1321 flying along the first flight trajectory, a second flying tool 1321 is released by a second virtual object 1302 within the target range of the first flying tool 1321. When a flyable implement (not shown in FIG. 15 ) is detected, it is assumed that the first flyable implement 1321 has collided with the second flyable implement, and in this case, a new circular path 1500 is generated for the first flyable implement 1321, where the circular path 1500 may be a circular or elliptical ring surrounding the first virtual object 1301, and the first virtual object 1301 may be located at the center or any position inside the circular path 1500, and the circular path 1500 is an exemplary illustration of a second flight path.

[0081] 13 and 15, the first flying tool originally moves according to a preset first flight trajectory, and disappears after reaching its validity period, flight distance, or collision with another virtual object (and causing a certain effect, which may be a gain effect, a loss effect, etc.). However, the technical solution provided by the embodiments of the present application can provide a new flight trajectory conversion interaction manner after the first flying tool collides with the second flying tool, in which the first flying tool switches from its original linear trajectory to a circular trajectory, which greatly improves the tool resource utilization rate of the first flying tool, and also provides more diverse flight modes, thereby improving the efficiency of human-machine interaction.

[0082] In some other embodiments, when the virtual skill can release multiple first flyable implements, the second flight trajectories may be multiple circular trajectories surrounding the first virtual object, and the multiple circular trajectories may be arranged in a concentric circle layout with the first virtual object at the center, or the multiple circular trajectories may be arranged in a series of intersecting non-concentric circles, although this is not specifically limited in the embodiments of the present application. In this manner, after detecting that a second flyable implement exists within the target range of any first flyable implement, the device controls all of the first flyable implements released by the virtual skill to move along their respective second flight trajectories, which is equivalent to switching from the original movement of all of the first flyable implements along their respective linear trajectories to the movement of all of the first flyable implements around the first virtual object along their respective circular trajectories after any first flyable implement collides with the second flyable implement.

[0083] As shown in FIG. 16, FIG. 16 is a schematic diagram of the circular trajectories of a plurality of first flying implements provided by an embodiment of the present application. The user shown in FIG. 14 controls a first virtual object 1401 to release a virtual skill 1411, thereby summoning a plurality of first flying implements 1421 in the virtual scene 1400. During the process of any of the first flying implements 1421 flying along the first flight trajectory, a second flying implement (not shown in FIG. 16) released by a second virtual object 1402 within the target range of any of the first flying implements 1421 may fly along the first flight trajectory. If a collision is detected, the first flyable implement 1421 is considered to have collided with a second flyable implement, and in this case, one new circular path 1600 is generated for each first flyable implement 1421, where the circular path 1600 may be a circular or elliptical ring surrounding the first virtual object 1401, and different circular paths 1600 may form concentric or non-concentric rings, and the first virtual object 1401 may be located at the center or any position inside each circular path 1600, and the circular paths 1600 are an exemplary illustration of second flight paths.

[0084] 14 and 16, originally, a plurality of first flying tools move according to their respective preset first flight trajectories, and disappear after reaching their effective period, flight distance, or collision with another virtual object (and causing a certain effect, which may be a gain effect, a loss effect, etc.). However, the technical solution provided by the embodiments of the present application provides a new flight trajectory conversion interaction manner after any of the first flying tools collides with a second flying tool, and each of the first flying tools can switch from its original linear trajectory to a circular trajectory, which greatly improves the tool resource utilization rate of the first flying tools, and also provides more diverse flight modes and improves the efficiency of human-machine interaction.

[0085] In the above process, originally in MOBA games, each type of flying prop is usually specific to a specified virtual skill of a specified virtual object. However, flying props have a limited validity period and a fixed flight mode (moving along a first flight trajectory), resulting in low tool resource utilization for the flying props designed by many engineers. However, the technical solution provided by the embodiments of the present application designs an innovative interaction mode based on flying props, so that when flying props from different sides collide, the flight trajectory of one of the flying props will be changed, making the flight trajectories of the flying props more varied and not limited to pre-set flight trajectories, thereby enriching the expressiveness of the game, improving tool resource utilization, and enhancing man-machine interaction efficiency.

[0086] Furthermore, when a flying tool moves along a fixed flight trajectory and collides with a flying tool of another team, its flight trajectory will be changed. Therefore, during a game between virtual objects of different teams, when a virtual object of a first team releases a virtual skill to summon a first flying tool to attack a virtual object of a second team along the first flight trajectory, the virtual object of the second team can release a virtual skill to summon a second flying tool to collide with the first flying tool, thereby causing the first flying tool to change its flight trajectory and be unable to attack the virtual object of the second team. Colliding with a flying tool is equivalent to blocking the flying tool and making it unable to function. This improves the flexibility of the flying tools while also expanding the functions of the flying tools, encouraging players to actively create game tactics around the flying tools and flexibly adjust game tactics using the flying tools, thereby enriching game play methods, contributing to players' increased willingness to participate in games, improving man-machine interaction efficiency, and enhancing players' game experience.

[0087] All the above alternative technical solutions can be used in any combination to form alternative embodiments of the present disclosure, and no further details are needed here.

[0088] The technical solution provided by the embodiments of the present application is that when a second flying tool is detected within the target range of a first flying tool, the first flying tool is controlled to switch from the first flight trajectory to the second flight trajectory because the first flying tool and the second flying tool are in different camps. This allows the flight trajectory of the first flying tool to be more varied as the game progresses, thereby increasing the tool resource utilization rate for the first flying tool, enriching the interaction methods based on the flying tools, and improving the efficiency of man-machine interaction.

[0089] While the above embodiment briefly introduces the flow of interaction based on a flying tool, this embodiment will now provide a detailed description of each step. Figure 17 is a flowchart of an interaction method based on a flying tool provided by an embodiment of the present application. Referring to Figure 17, this embodiment is performed by an electronic device, and the electronic device is a terminal, and this embodiment includes steps 1701 to 1705.

[0090] 1701, in response to a release operation of a virtual skill by a first virtual object, the terminal creates a first flyable tool in the virtual scene, the first flyable tool is associated with the virtual skill, and the first virtual object belongs to a first camp.

[0091] The above step 1701 is based on the same principle as step 1201 in the above embodiment, and no further explanation is needed here.

[0092] In some embodiments, the terminal can create and manage the first flyable implement through a profile, where the profile has multiple tracks, and each track is used to manage one type of business logic of the first flyable implement. Illustratively, the profile of the first flyable implement can have five tracks, including, from top to bottom, the following: 1|SpawnObjectDuration0 / / Spawns one entity 2|SetCollisionTick0 / / Adds a collision detection window for this entity. 3|TriggerParticle3 / / Adds a special effect for this entity 4|MoveBulletDuration4 / / Move the entity 5|HitTriggerDuration0 / / Adds collision detection logic to this entity.

[0093] The above entity refers to the first entity of the first flyable tool created in the virtual scene, i.e., the initial entity of the first flyable tool, and the above special effect refers to the first special effect possessed by the first entity of the first flyable tool created in the virtual scene, i.e., the initial special effect of the first flyable tool.

[0094] During the execution of the game application, the terminal can search for a profile of the first flyable prop in the cache and execute the profile, thereby sequentially executing the business logic of each track from top to bottom to create an entity with a special effect as the first flyable prop in the virtual scene, and the first flyable prop moves according to the release direction specified by the release operation, that is, the first flyable prop moves according to the first flight trajectory, and generates a certain effect on non-teammate virtual objects that it collides with along the way. The above profile is one possible embodiment of the prop resource of the first flyable prop.

[0095] In one exemplary scene, taking the first flying tool as an example, when the terminal detects that the user controls the first virtual object to release the virtual skill, it calls the function node “1|SpawnBulletTick0” of the game application to generate a Bullet object, and the Bullet object is an Actor object in the game application. Then, it uses the skill ID of the virtual skill as an index to query the profile of the first flying tool in the cache, and realizes initialization and configuration for the Bullet object according to the business logic provided by each track in the profile, so that the first flying tool can be displayed in the virtual scene and can be controlled to move along a first flight trajectory.

[0096] 1702, the terminal controls the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation.

[0097] The above step 1702 is based on the same principle as step 1202 in the previous embodiment, and no further explanation is needed here.

[0098] For example, the terminal can define the first flight trajectory by “4|MoveBulletDuration4”, which is a track in the profile of the first flyable tool. For example, the terminal can define the first flight trajectory as a ray trajectory starting from the first virtual object and heading toward the release direction of the virtual skill, or the terminal can define the first flight trajectory as a straight line trajectory heading toward the release direction of the virtual skill, or the terminal can define the first flight trajectory as an arc trajectory, a curved trajectory, a parabolic trajectory, etc. according to a set trajectory function. Here, the specific type of the first flight trajectory is not limited.

[0099] The first flight trajectory refers to a fixed trajectory preset for the first flyable tool in the profile, and does not change as the game progresses. That is, no matter at what point in the game the user controls the first virtual object to release a virtual skill, the created first flyable tool will first move according to the first flight trajectory.

[0100] 1703, when a second flyable tool is detected within the target range of the first flyable tool, the terminal controls the first flyable tool to stop moving on the first flight trajectory, and the second flyable tool is released by a second virtual object of the second camp.

[0101] In some embodiments, the terminal may add a collision detection frame for the first flyable implement. The collision detection frame may be a collision detection box (also referred to as a collision detection range) mounted on the implement model of the first flyable implement. The collision detection frame can move along with the movement of the first flyable implement, ensuring that the first flyable implement performs collision detection in real time during its movement. Optionally, the range enclosed by the collision detection frame is a target range. The technician can define the size of the target range using the track "2|SetCollisionTick0" in the profile. The size of the target range is not specifically limited here. Note that if a virtual skill releases multiple first flyable implements, each first flyable implement may be equipped with a collision detection frame. Alternatively, if the first flight trajectories of the multiple first flyable implements are relatively compact, all first flyable implements may be equipped with a single collision detection frame with a large range for convenience. This is not specifically limited here.

[0102] In some embodiments, after the device implements a collision detection window for a first flyable tool released by a first virtual object, the device also implements a collision detection window for a second flyable tool released by a second virtual object using the same principle. In this manner, the device can determine whether the second flyable tool is included in the target range of the first flyable tool by determining whether the collision detection window of the first flyable tool intersects with the collision detection window of the second flyable tool. If the collision detection window of the first flyable tool intersects with the collision detection window of the second flyable tool, the device determines that the second flyable tool is included in the target range of the first flyable tool. If the collision detection window of the first flyable tool does not intersect with the collision detection window of the second flyable tool, the device determines that the second flyable tool is not included in the target range of the first flyable tool.

[0103] As shown in FIG. 18, FIG. 18 is a diagram illustrating the principle of the collision detection method provided by the embodiment of the present application. In a virtual scene 1800, if a second virtual object 1802 releases a virtual skill to summon a second flying tool 1810, a spherical collision detection frame 1811 is mounted on the tool model of the second flying tool 1810, and the collision detection frame 1811 of the second flying tool 1810 intersects with the collision detection frame 1803 mounted on the character model of the first virtual object 1801, thereby causing the second flying tool 1810 to fly. 0 indicates that the first virtual object 1801 has been hit, and therefore the second flying tool 1810 produces a corresponding effect on the first virtual object 1801, such as deducting a certain virtual life value from the first virtual object 1801, or deducting a certain virtual defense value from the first virtual object 1801, or reducing the attack power coefficient of the first virtual object 1801 within a set time, and the effect of the flying tool is not specifically limited here.

[0104] In addition to the second flyable tool in the virtual scene, the flyable tool released by the teammate's virtual object, the virtual object itself, neutral virtual objects such as field monsters, and even some virtual objects may also be equipped with collision detection frames. Therefore, when the terminal detects that the collision detection frame of the first flyable tool intersects with any of the collision detection frames, it considers that an obstacle has been detected within the target range of the first flyable tool. However, before deciding whether to change the flight trajectory of the first flyable tool, it needs to determine whether the obstacle is the second flyable tool.

[0105] In some embodiments, the method for detecting whether an obstacle within the target range is a second flyable implement includes the following steps 1713-1733.

[0106] 1713, if a virtual object is detected within the target range of the first flyable tool, obtain an object type of the virtual object.

[0107] In some embodiments, when the terminal detects that the collision detection frame of the first flyable tool intersects with any collision detection frame, it considers that an obstacle has been detected within the target range of the first flyable tool, and then queries the type of the obstacle. If the type of the obstacle is a flyable tool, it enters step 1723. If the type of the obstacle is a virtual object, it controls the first flyable tool to produce an effect on the virtual object according to the skill setting of the virtual skill, such as reducing the movement speed of the virtual object, lengthening the skill CD of the virtual object, reducing the virtual life value or virtual defensive power of the virtual object, etc.

[0108] 1723. If the type is a flying tool, obtain the faction to which the flying tool belongs.

[0109] In some embodiments, if the object type of the obstacle is a flying tool, the faction to which the flying tool belongs may be further determined, and if the flying tool belongs to the second faction, step 1733 may be entered, and if the flying tool belongs to the first faction, no processing may be performed and the flying tool may continue to move along the first flight trajectory.

[0110] 1733, if the camp is the second camp and the flying implement satisfies the adhesion condition, determine the obstacle as the second flying implement, and the adhesion condition indicates that the flying implement can transform the flight trajectory of another flying implement.

[0111] In some embodiments, if the flying tool belongs to the second group, it may further be determined whether the flying tool satisfies the adhesion conditions. For example, a list of tool IDs that satisfy the adhesion conditions may be stored in the terminal, and the tool ID list may be checked to see whether the tool ID of the flying tool of the second group detected within the target range is included in the tool ID list. If the tool ID of the flying tool is found in the list of tool IDs that satisfy the adhesion conditions, it may be determined that the flying tool satisfies the adhesion conditions and be determined as a second flying tool. If the tool ID of the flying tool is not found in the list of tool IDs that satisfy the adhesion conditions, it may be determined that the flying tool does not satisfy the adhesion conditions, that is, the flying tool does not support changing the flight trajectory of another flying tool that has collided with it, and other main business logic of the game may be executed to determine whether to perform no processing or to cancel or absorb one of the flying tools.

[0112] 19 is a diagram illustrating the principle of selecting a second flyable tool provided by an embodiment of the present application. As shown in FIG. 19, the first flyable tool is a first projectile, and the second flyable tool is a second projectile. The tool models of the first and second projectiles are each equipped with a collision detection frame. During the process of the first projectile moving along the first flight trajectory, if the collision detection frame of the first projectile intersects with a collision detection frame, it indicates that the first projectile has collided with an obstacle. Then, determine whether the obstacle is a flyable tool. If so, determine whether the flyable tool belongs to the second group. If so, determine whether the flyable tool satisfies the adsorption condition. If so, determine the flyable tool as the second flyable tool. Otherwise, if the result of any of the determination logics is negative, terminate the process.

[0113] In some embodiments, to conveniently determine whether a flying tool satisfies the attraction condition, when creating a profile for each flying tool, the profile may typically record attribute information for the flying tool, which may include the tool name of the flying tool, the tool ID, the skill ID of the virtual skill to which it belongs, the object ID of the virtual object to which it belongs, the faction ID to which it belongs, etc. Next, a new attraction attribute field is created in the attribute information, and a value of the attraction attribute field of True indicates that the flying tool satisfies the attraction condition, and a value of the attraction attribute field of False indicates that the flying tool does not satisfy the attraction condition. Furthermore, a technician may set the attraction attribute field to either default to satisfy the attraction condition or not satisfy the attraction condition. In this way, after the first flyable tool collides with an obstacle within the target range, by simply accessing the attribute information in the obstacle's profile, it is possible to determine whether the obstacle is a flyable tool according to the obstacle's ID, determine whether the flyable tool belongs to the second group according to the group ID, and determine whether the adhesion condition is met according to the adhesion attribute field. If the object type is a flyable tool, belongs to the second group, and meets the adhesion condition at the same time, it is determined that a second flyable tool has been detected within the target range of the first flyable tool, and step 1704 is entered.

[0114] JPEG2025534005000002.jpg197170

[0115] Steps 1713-1733 set multiple determination logics for detecting whether an obstacle within the target range is a second flyable prop. Optionally, the same or different determination logics can be set for different first flyable props released by different virtual skills according to the requirements of the game service. For example, for some types of first flyable props, determining whether they satisfy the adhesion condition can be omitted. This can provide more flexible and varied battle tactics and play experiences, contributing to enriching the interaction methods based on the flyable props. Furthermore, the multiple determination logics in steps 1713-1733 can ensure that the second flyable prop is a flyable prop belonging to the second team and satisfies the adhesion condition. This can prevent a collision with a flyable prop released by a teammate's virtual object, which would change its flight trajectory and cause an error in the subsequent game service logic.

[0116] In some embodiments, after steps 1713-1733 detect that a second flyable implement exists within the target range of the first flyable implement, i.e., the collision detection frame of the first flyable implement intersects with the collision detection frame of the second flyable implement, it is necessary to control the first flyable implement to stop moving along the first flight trajectory, and further, the collision detection function and implement movement function of the first flyable implement may be immediately stopped, thereby preventing the first flyable implement from continuing to move along the first flight trajectory and causing injury.

[0117] In one example, the first flying tool is a first projectile, and the Action being performed by the first projectile is obtained through the Actor object of the first projectile, and then the track type to which the current Action belongs is detected by analyzing the track in the profile of the first projectile, and then the target track to which the current Action belongs is stopped.

[0118] JPEG2025534005000003.jpg102170

[0119] At 1704, the terminal generates a second flight trajectory for the first flyable implement and controls the first flyable implement to move along the second flight trajectory.

[0120] In some embodiments, after stopping the movement of the first flyable implement in the first flight trajectory, the first flyable implement can be launched again using a new second flight trajectory, thereby realizing a transformation to the flight trajectory of the first flyable implement, where the second flight trajectory is different from the first flight trajectory.

[0121] In some embodiments, the device may first disable the business logic of the collision detection function and the tool movement function of the first flyable tool in the first flight trajectory, and then re-apply new business logic to the first flyable tool, thereby avoiding correcting the unique profile of the first flyable tool and thereby avoiding destroying the unique business logic of the first flyable tool, and avoiding uncontrollable performance when the user subsequently releases the virtual skill to summon the first flyable tool. In view of this, to change the flight trajectory of the first flyable tool, a second entity may be created again for the first flyable tool, and the second entity may be combined with the first entity of the first flyable tool, where the first entity is an initial entity when the first flyable tool is created, and the second entity is a new entity created after the first flyable tool collides with the second flyable tool.

[0122] In some embodiments, the device may first create a second entity with a second special effect for the first flyable tool, where the second entity inherits the first entity for the first flyable tool, and the second special effect inherits the first special effect of the first entity. That is, as described in step 1701 above, when summoning the first flyable tool, an entity has already been created and a special effect added for the first flyable tool, where the first entity is the created initial entity and the first special effect is the added initial special effect. Therefore, when creating a second entity and adding a second special effect for the first flyable tool, two steps, namely, creating an entity and adding a special effect in the profile, can be skipped. Instead, a second entity with a second special effect is obtained by inheriting the first entity with the first special effect, and then a tool movement function for the first flyable tool along a second flight trajectory is created.

[0123] In some embodiments, after creating the second entity, the terminal can create a second flight trajectory for the second entity based on the collision position between the first flyable tool and the second flyable tool. For example, a Loop function can be used to set the second flight trajectory to be a circular trajectory surrounding the first virtual object. In this way, when the first flyable tool can be controlled to move along the second flight trajectory, what is actually performed is a circular movement around the first virtual object, and the center, radius, etc. of the circular trajectory are all defined and adjusted by the Loop function.

[0124] In one example, a profile to create a second entity for a first flyable implement is as follows: 1 | Acquire the second flying tool that the first flying tool collided with. 2|LoopBulletDuration0 / / Sets the second entity to perform an orbital movement around the first virtual object 3|ExtendBulletDuration0 / / Extend the validity period of the second entity.

[0125] In the above process, a second entity is created again for the first flying tool, and a second flight trajectory is generated by the second entity, so that the movement of the first flying tool can be controlled by a completely new profile, and the second entity and the second special effect inherit the first entity and the first special effect, which simplifies the process of creating a completely new profile and saves terminal processing resources.

[0126] Furthermore, the last track in the above completely new profile, "3|ExtendBulletDuration0", can control the validity period of the first flying tool after changing the flight trajectory, and can flexibly extend the validity period (even infinitely) according to business requirements, or discard the track (i.e., discard the first flying tool).

[0127] In the above steps 1703-1704, a possible embodiment is provided in which, if a second flyable tool is detected within the target range of the first flyable tool, the first flyable tool is controlled to move along a second flight trajectory, by stopping the movement of the first flyable tool along the first flight trajectory, creating a second entity with a second special effect to inherit the first entity with the first special effect, generating a second flight trajectory for the second entity, and controlling the first flyable tool to move along the second flight trajectory through the profile of the second entity, thereby switching the flight trajectory of the first flyable tool from the first flight trajectory to the second flight trajectory, which is equivalent to re-launching (or releasing) the first flyable tool along the second flight trajectory, which avoids destroying the unique profile of the first flyable tool, and furthermore, the validity period of the first flyable tool can be flexibly adjusted through the profile of the second entity, which has a high degree of development freedom.

[0128] In some embodiments, when a virtual skill releases multiple first flyable implements at the same time, the above-described second entity creation and second flight trajectory generation operations can be performed for each first flyable implement. However, to facilitate unified management of multiple first flyable implements released by the same virtual skill and ensure that multiple first flyable implements released by the same virtual skill simultaneously change their flight trajectories, the terminal can further maintain a flyable implement management array for managing the flyable implements whose flight trajectories have been changed in the virtual scene. For example, the terminal can maintain the flyable implement management array in a Blueprint tool of a game engine, or can maintain the flyable implement array using other development tools.

[0129] Based on the above, after creating the second entity, the terminal can notify the flying implement management array of a trajectory transformation event of the first flying implement and add the first flying implement to the flying implement management array. In this way, every time the generation of the second flight trajectory of a first flying implement is completed, the terminal can notify the flying implement management array of a trajectory transformation event of the first flying implement and add the first flying implement to the flying implement management array, thereby conveniently managing multiple first flying implements released at the same time by the same virtual skill and ensuring that the first flying implements simultaneously transform their flight trajectories, extend their validity periods, and are discarded.

[0130] In one example, to facilitate management of the flyable implement management array, the profile of the second entity can be adjusted to track logic as follows: 1 | Acquire the second flying tool that the first flying tool collided with. 2|Generate the second flight trajectory 3|Generate a second entity (using the Blueprint tool) 4 | Notify Blueprint that the first flying implement has switched flight trajectory 5 | Re-launch the first flying tool along the second flight trajectory 6 | Extend the AGE validity period of the first flying tool 7|PrintTick0

[0131] As shown in Figure 20, Figure 20 is a schematic diagram of the blueprint tool provided in the embodiment of the present application. In the blueprint tool, a target array, i.e., a flying tool management array, is created by the ActorRoot array addition function, and a first flying tool Bullet, whose flight trajectory has been converted, is added to the flying tool management array.

[0132] In the above method, the flying prop management array can conveniently manage the flying props that are summoned and have their flight trajectories changed by each virtual object in a game match when they release their virtual skills. In this way, after the flying props change their flight trajectories, whether the flying props' validity period is extended or these flying props are uniformly discarded, the main business logic of the game only needs to notify the flying prop management array in the blueprint tool through an event, so that the flying props with their flight trajectories changed can be uniformly managed and controlled, which has high flexibility and freedom and can be flexibly adjusted according to the requirements of the game service.

[0133] In some embodiments, when a second flyable implement is detected within a target range of the first flyable implement, the first flyable implement is controlled to move along a second trajectory and the display of the second flyable implement is canceled. Canceling the display of the second flyable implement indicates that the second flyable implement has been counterbalanced, destroyed, or attracted. That is, when two flyable implements collide, one flyable implement changes its trajectory and the other flyable implement is counterbalanced, destroyed, or attracted.

[0134] In some other embodiments, after a second flight trajectory is generated for a first flying tool, the first flying tool collides with a second flying tool, and then the flight trajectory is changed. In this case, it is possible to determine which flying tool's flight trajectory will be changed according to the skill setting of the virtual skill or by comparing the skill levels of the first virtual object and the second virtual object. The remaining flying tools can be canceled out, destroyed, or attracted (or absorbed) by the first flying tool, or continue to move along their original fixed trajectories, etc., which can be flexibly set by engineers according to game service requirements. In the embodiments of the present application, an example will be described in which the first flying tool changes its flight trajectory.

[0135] When the first flying implement changes its flight trajectory and the second flying implement is absorbed by the first flying implement, the terminal can further change the form of the first flying implement based on the second flying implement, the form including at least one of the entity shape or special flight effect of the first flying implement. That is, when the second flying implement is absorbed by the first flying implement, the first flying implement can be changed in form according to the second flying implement, so that the transformed first flying implement has a partial entity shape or special flight effect of the second flying implement, or a composite shape or special effect of both. The terminal then controls the transformed first flying implement to move along the second flight trajectory. This allows the user to see at a glance that the two flying implements have merged after colliding, thereby improving the user's information acquisition efficiency.

[0136] In some embodiments, the form includes two aspects: entity shape and flying special effect, so the terminal can change the form of the first flying tool by any one of the following methods 1714 to 1734.

[0137] 1714, the terminal reserves the entity shape of the first flyable implement and assigns the flight special effect of the second flyable implement to the first flyable implement.

[0138] In some embodiments, after creating the second entity, the terminal allows the second entity to inherit the entity shape of the first flying tool and the special flight effects of the second flying tool, so that the second entity retains the entity shape of the first flying tool and combines it with the special flight effects of the second flying tool, achieving a relatively harmonious and natural fusion effect, and intuitively embodying the second flying tool being adsorbed by the first flying tool.

[0139] At 1724, the terminal reserves the flight special effect of the first flyable implement and assigns the entity shape of the second flyable implement to the first flyable implement.

[0140] In some embodiments, after creating the second entity, the terminal allows the second entity to inherit the entity shape of the second flying tool and the special flight effect of the first flying tool, so that the second entity retains the entity shape of the second flying tool and combines it with the special flight effect of the first flying tool, achieving a relatively harmonious and natural fusion effect, and also intuitively embodying the second flying tool being adsorbed by the first flying tool.

[0141] At 1734, the terminal determines a target configuration based on the first flyable implement configuration and the second flyable implement configuration, and assigns the target configuration to the first flyable implement.

[0142] In some embodiments, after creating the second entity, the terminal may combine the entity shape of the first flyable implement with the entity shape of the second flyable implement to obtain the entity shape of the second entity, for example, by combining the entity shape of the second entity using the entity outline of the first flyable implement and the entity color scheme of the second flyable implement, or by combining the entity shape of the second entity using the entity outline of the second flyable implement and the entity color scheme of the first flyable implement, or by retaining the entity outline of the first flyable implement, and then combine the texture mappings of the first flyable implement and the second flyable implement using a trained image fusion model to obtain a new target texture mapping, where the implement model of the first flyable implement is rendered using the target texture mapping, and the target texture mapping may combine the texture features or style features of both texture mappings, etc. The image fusion model is not specifically limited here.

[0143] In some embodiments, after creating the second entity, the terminal may combine the special flight effect of the first flying tool with the special flight effect of the second flying tool to obtain the special flight effect of the second entity, for example, by simply overlapping the special flight effects of two flying tools; or, when a virtual skill releases multiple first flying tools, some of the first flying tools may retain their own special flight effect, and other parts of the first flying tools may adopt the special flight effect of the second flying tool, and the embodiments of the present application are not specifically limited thereto.

[0144] In the above method, the form of the first flyable tool is changed based on the second flyable tool, and in this way, at least one of the entity shape or special flight effect of the first flyable tool can be changed, so that the two flyable tools achieve a relatively harmonious and natural fusion effect, which also intuitively embodies the second flyable tool being adsorbed by the first flyable tool, and improves the user's information acquisition efficiency.

[0145] 1705, the terminal extends the validity period of the first flyable tool.

[0146] In some embodiments, the terminal may extend the validity period of the first flying implement using the track "3|ExtendBulletDuration0" in the profile of the second entity, as introduced in step 1704 above. The extension of the validity period may be set by a technician, for example, extending the validity period by 5 seconds or other value each time a collision with a second flying implement occurs, or extending the validity period by 10 seconds or other value only upon the first collision with a second flying implement, or continuously extending the validity period of the first flying implement and discarding it uniformly through the main business logic during the game, thereby meeting flexible and variable business requirements.

[0147] In the above step 1705, if a second flyable tool is detected within the target range of the first flyable tool, the validity period of the first flyable tool is extended, thereby significantly increasing the display time length of the first flyable tool in the MOBA game, thereby improving the tool resource utilization rate in terms of extending the validity period.

[0148] All the above alternative technical solutions can be used in any combination to form alternative embodiments of the present disclosure, and no further details are needed here.

[0149] The technical solution provided by the embodiments of the present application is that when a second flying tool is detected within the target range of a first flying tool, the first flying tool is controlled to switch from the first flight trajectory to the second flight trajectory because the first flying tool and the second flying tool are in different camps. This allows the flight trajectory of the first flying tool to be more varied as the game progresses, thereby increasing the tool resource utilization rate for the first flying tool, enriching the interaction methods based on the flying tools, and improving the efficiency of man-machine interaction.

[0150] The above embodiment provides a detailed introduction to the processing logic after the collision of two flying props from different camps. In the embodiment of the present application, the flying props from two different camps are explained as projectiles from two different camps as an example, and the first flying prop released by the first virtual object of the first camp is called the first projectile, and the second flying prop released by the second virtual object of the second camp is called the second projectile.

[0151] As shown in FIG. 21, FIG. 21 is a principle diagram of an interaction method based on a flying tool provided in an embodiment of the present application, which is executed by an electronic device, and is described by taking the electronic device as a terminal as an example, and this embodiment includes steps 2101 to 2111, namely: Step 2101: After the user controls the first virtual object of the first camp to release the virtual skill, the terminal creates a first projectile of the virtual skill and turns on the suction function of the first projectile. Step 2102: The terminal generates a collision detection frame for the first projectile and implements the collision detection function. Step 2103: The terminal performs real-time collision detection on the first projectile based on the collision detection window. Step 2104: If an obstacle is detected in the collision detection window, the terminal determines whether the obstacle is a projectile, and if so, enters step 2105; otherwise, no processing is performed. Step 2105, the terminal determines whether the projectile belongs to the second camp, if so, enters step 2106, otherwise, no processing is performed. Step 2106: The terminal determines whether the projectile satisfies the adsorption condition, and if so, enters step 2107; otherwise, no processing is performed. In step 2107, the terminal controls the first projectile to stop moving on the first flight trajectory. In step 2108, the terminal stops the collision detection logic for the first projectile. In step 2109, the terminal creates a new entity for the first projectile and controls the first projectile again through the new entity. In step 2110, the terminal records the first projectile in the Blueprint tool for use in subsequent game service flows. In step 2111, the terminal executes the subsequent steps, for example, re-launching the first projectile with a second flight trajectory and extending the validity period of the first projectile.

[0152] The technical solution provided by the embodiments of the present application is that for a projectile carried by a virtual skill, after detecting a collision between two projectiles from different camps through a collision detection function, the projectile from one camp is controlled to be attracted to the projectile from the other camp, thereby changing the flight trajectory of the projectile from the other camp and extending its effective period, thereby extending the presentation time of the projectile and enriching the flight trajectory of the projectile, greatly improving the tool resource utilization rate of the projectile, enriching the interaction methods based on the projectile, and improving the efficiency of man-machine interaction.

[0153] FIG. 22 is a structural diagram of an interaction device based on a flying tool provided by an embodiment of the present application. As shown in FIG. 22, the device includes: a creation module 2201 for creating a first flyable tool in the virtual scene in response to a release operation of a virtual skill by a first virtual object, the first flyable tool being associated with the virtual skill and the first virtual object belonging to a first camp; a first control module (2202) for controlling the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation; and a second control module (2203) for controlling the first flyable implement to move along a second flight trajectory if a second flyable implement is detected within the target range of the first flyable implement, wherein the second flyable implement is released by a second virtual object, the second virtual object belonging to a second camp.

[0154] The technical solution provided by the embodiments of the present application is that when a second flying tool is detected within the target range of a first flying tool, the first flying tool is controlled to switch from the first flight trajectory to the second flight trajectory because the first flying tool and the second flying tool are in different camps. This allows the flight trajectory of the first flying tool to be more varied as the game progresses, thereby increasing the tool resource utilization rate for the first flying tool, enriching the interaction methods based on the flying tools, and improving the efficiency of man-machine interaction.

[0155] In some embodiments, based on the configuration of the device of FIG. 22, the device: if an obstacle is detected within a target range of the first flyable implement, obtain a type of the obstacle; If the type is a flying tool, obtain the camp to which the flying tool belongs, If the camp is the second camp and the flying implement satisfies the adhesion condition, the obstacle is determined to be the second flying implement, and the adhesion condition further includes a detection module for indicating that the flying implement can transform the flight trajectory of another flying implement.

[0156] In some embodiments, based on the configuration of the device of FIG. 22, the second control module 2203: a first control unit for controlling the first flyable implement to stop movement along the first flight trajectory; a generation unit for generating the second flight trajectory for the first flyable implement; and a second control unit for controlling the first flyable implement to move along the second flight trajectory.

[0157] In some embodiments, the generating unit comprises: creating a second entity having a second special effect for the first flyable implement, the second entity inheriting the first entity of the first flyable implement, and the second special effect inheriting the first special effect of the first entity; The second flight trajectory for the second entity is created based on a collision location between the first flyable implement and the second flyable implement.

[0158] In some embodiments, the generating unit further comprises: A flyable tool management array is notified of the trajectory transformation event of the first flyable tool, and the first flyable tool is added to the flyable tool management array, which is used to manage the flyable tool whose flight trajectory has been transformed in the virtual scene.

[0159] In some embodiments, based on the configuration of the device of FIG. 22, the device: The system further includes an extension module for extending an effective period of the first flyable implement when a second flyable implement is detected within a target range of the first flyable implement.

[0160] In some embodiments, the first flight trajectory is a linear trajectory and the second flight trajectory is a circular trajectory that surrounds the first virtual object.

[0161] In some embodiments, based on the configuration of the device of FIG. 22, the device: a modification module for modifying a configuration of the first flyable implement based on the second flyable implement, the configuration including at least one of an entity shape or a flight special effect of the first flyable implement; The second control module 2203 further controls the reconfigured first flyable implement to move along the second flight trajectory.

[0162] In some embodiments, the modification module: Retaining the entity shape of the first flyable implement and assigning the flight special effect of the second flyable implement to the first flyable implement; or Suspending the flight special effect of the first flyable implement and assigning the entity shape of the second flyable implement to the first flyable implement; or A target configuration is determined based on the first flyable implement configuration and the second flyable implement configuration, and the target configuration is assigned to the first flyable implement.

[0163] In some embodiments, the second control module 2203: If a second flyable implement is detected within the target range of the first flyable implement, the first flyable implement is controlled to move along the second flight trajectory and the display of the second flyable implement is cancelled.

[0164] All the above alternative technical solutions can be used in any combination to form alternative embodiments of the present disclosure, and no further details are needed here.

[0165] It should be noted that the flying tool-based interaction device provided in the above embodiments only takes the division of each of the above functional modules as an example when performing interaction based on a flying tool, and in actual application, the above functions can be allocated to different functional modules as needed to complete them, that is, all or part of the above functions can be completed by dividing the internal structure of the electronic device into different functional modules. Furthermore, the flying tool-based interaction device and the flying tool-based interaction method provided in the above embodiments belong to the same concept, and the specific implementation process thereof should be referred to in detail in the flying tool-based interaction method embodiment, and no further details are needed here.

[0166] FIG. 23 is a structural schematic diagram of a terminal provided by an embodiment of the present application. As shown in FIG. 23, the terminal 2300 is an exemplary illustration of an electronic device. Optionally, the device type of the terminal 2300 includes a smartphone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III, a moving picture experts compressed standard audio layer 3), an MP4 (Moving Picture Experts Group Audio Layer IV, a moving picture experts compressed standard audio layer 4) player, a laptop computer, or a desktop computer. The terminal 2300 may also be referred to as a user device, a portable terminal, a laptop terminal, a desktop terminal, or other names. Typically, the terminal 2300 includes a processor 2301 and a memory 2302.

[0167] Optionally, the processor 2301 includes one or more processing cores, such as a 4-core processor, an 8-core processor, etc. Optionally, the processor 2301 is implemented using at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), or a PLA (Programmable Logic Array). In some embodiments, the processor 2301 includes a main processor and a coprocessor, where the main processor is a processor for processing data in a wake-up state and is also referred to as a CPU (Central Processing Unit), and the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 2301 integrates a GPU (Graphics Processing Unit), which is used to render and draw content that needs to be displayed on a display screen. In some embodiments, the processor 2301 further includes an AI (Artificial Intelligence) processor, which is used to process computational operations related to machine learning.

[0168] In some embodiments, memory 2302 includes one or more computer-readable storage media, and optionally the computer-readable storage media are non-transitory. Optionally, memory 2302 further includes high-speed random access memory and non-volatile memory, such as one or more magnetic disk storage devices or flash memory storage devices. In some embodiments, the non-transitory computer-readable storage media in memory 2302 are used to store at least one program code that is executed by processor 2301 to implement the flyable implement-based interaction methods provided by the embodiments of the present application.

[0169] In some embodiments, terminal 2300 optionally further includes a peripheral interface 2303 and at least one peripheral. The processor 2301, memory 2302, and peripheral interface 2303 may be connected via a bus or signal lines. Each peripheral may be connected to peripheral interface 2303 via a bus, signal line, or wiring board. Specifically, the peripherals may include at least one of a radio frequency circuit 2304, a display screen 2305, a camera component 2306, an audio circuit 2307, and a power supply 2308.

[0170] Peripheral interface 2303 may be used to connect at least one peripheral associated with I / O (Input / Output) to processor 2301, memory 2302. In some embodiments, processor 2301, memory 2302, and peripheral interface 2303 are integrated on the same chip or wiring board, while in some other embodiments, any one or two of processor 2301, memory 2302, and peripheral interface 2303 are implemented on separate chips or wiring boards.

[0171] The radio frequency circuitry 2304 is used to transmit and receive RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuitry 2304 communicates with communication networks and other communication devices via electromagnetic signals. The radio frequency circuitry 2304 converts electrical signals into electromagnetic signals to transmit or converts received electromagnetic signals into electrical signals. Optionally, the radio frequency circuitry 2304 includes an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a CODEC chipset, a subscriber identity module card, etc.

[0172] The display screen 2305 is used to display a UI (User Interface). Optionally, the UI includes graphics, text, icons, video, and any combination thereof. If the display screen 2305 is a touchscreen, the display screen 2305 is further capable of collecting touch signals on or above the surface of the display screen 2305. The touch signals can be input as control signals to the processor 2301 for processing.

[0173] The camera component 2306 is used to capture images or videos. Optionally, the camera component 2306 includes a front camera and a rear camera. Typically, the front camera is located on the front panel of the terminal, and the rear camera is located on the back of the terminal. In some embodiments, there are at least two rear cameras, each of which is any one of a main camera, a depth-of-field camera, a wide-angle camera, and a telephoto camera. This allows the main camera and the depth-of-field camera to be combined to realize a background blur function, and the main camera and the wide-angle camera to realize panoramic photography, VR (Virtual Reality) photography, or other fusion photography functions.

[0174] In some embodiments, audio circuitry 2307 includes a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment and convert the sound waves into electrical signals that are input to processor 2301 for processing or input to radio frequency circuitry 2304 for voice communication. For purposes of stereo collection or noise reduction, multiple microphones may be used, each located at a different part of terminal 2300.

[0175] The power source 2308 is used to power each component of the terminal 2300. Optionally, the power source 2308 is AC, DC, a disposable battery, or a rechargeable battery. If the power source 2308 includes a rechargeable battery, the rechargeable battery supports wired or wireless charging. The rechargeable battery may also be used to support fast charging technology.

[0176] As will be appreciated by those skilled in the art, the structure shown in FIG. 23 does not constitute a limitation on terminal 2300, which may include more or fewer components than shown, may combine some components, or may employ a different arrangement of components.

[0177] 24 is a structural schematic diagram of an electronic device provided by an embodiment of the present application, where the electronic device 2400 has relatively large differences due to differences in configuration or performance. The electronic device 2400 includes one or more processors (Central Processing Units, CPUs) 2401 and one or more memories 2402. The memories 2402 store at least one computer program, which is loaded and executed by the one or more processors 2401 to realize the interaction method based on a flyable tool provided by each of the above embodiments. Optionally, for convenient input and output, the electronic device 2400 may further include components such as a wired or wireless network interface, a keyboard, and an input / output interface. The electronic device 2400 may also include other components for realizing device functions, which are not required to be detailed here.

[0178] In an exemplary embodiment, a computer-readable storage medium is further provided, for example, including a memory for at least one computer program, which can be executed by a processor in the electronic device to implement the interaction method based on the flyable implement in each of the above embodiments. For example, the computer-readable storage medium includes a ROM (Read-Only Memory), a RAM (Random-Access Memory), a CD-ROM (Compact Disc Read-Only Memory), a magnetic tape, a flexible disk, an optical data storage device, etc.

[0179] An exemplary embodiment further provides a computer program product including one or more computer programs, the one or more computer programs being stored in a computer-readable storage medium, one or more processors of an electronic device being able to read the one or more computer programs from the computer-readable storage medium, and the one or more processors being able to execute the one or more computer programs to cause the electronic device to perform the interaction method based on the flyable tool in the embodiment.

[0180] As can be understood by those skilled in the art, all or part of the steps in the above embodiments can be realized by hardware, or can be realized by instructing the relevant hardware by a program, and optionally the program can be stored in a computer-readable storage medium, and optionally the above-mentioned storage medium can be a read-only memory, a magnetic disk, an optical disk, etc.

[0181] The above description is merely a possible embodiment of the present application, and is not intended to limit the present application. Any amendments, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included within the scope of protection of the present application.

Claims

1. 1. A flyable tool-based interaction method implemented by an electronic device, comprising: creating a first flyable tool in the virtual scene in response to a release operation of a virtual skill by a first virtual object, the first flyable tool being associated with the virtual skill and the first virtual object belonging to a first faction; controlling the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation; and controlling the first flyable implement to move along a second flight trajectory if a second flyable implement is detected within a target range of the first flyable implement, the second flyable implement being released by a second virtual object, the second virtual object belonging to a second faction, and the second flight trajectory being different from the first flight trajectory. A method characterized by:

2. detecting a second flyable implement within a target range of the first flyable implement; If an obstacle is detected within a target range of the first flyable implement, obtaining a type of the obstacle; If the type is a flying tool, acquiring a camp to which the flying tool belongs; determining the obstacle as the second flyable tool if the faction is the second faction and the flyable tool satisfies an adhesion condition, the adhesion condition indicating that the flyable tool can change the flight trajectory of another flyable tool; 2. The method of claim 1 .

3. controlling the first flyable implement to move along a second flight trajectory includes: controlling the first flyable implement to stop movement along the first flight trajectory; generating the second flight trajectory for the first flyable implement; and controlling the first flyable implement to move along the second flight trajectory.

3. The method according to claim 1 or 2.

4. generating the second flight trajectory for the first flyable implement, creating a second entity having a second special effect for the first flyable implement, the second entity inheriting the first entity of the first flyable implement and the second special effect inheriting the first special effect of the first entity; generating the second flight trajectory of the second entity based on a collision location between the first flyable implement and the second flyable implement; 4. The method of claim 3.

5. The method comprises: notifying a flyable tool management array of a trajectory transformation event of the first flyable tool, and adding the first flyable tool to the flyable tool management array, wherein the flyable tool management array is used to manage flyable tools whose flight trajectories have been transformed in the virtual scene; 5. The method of claim 4.

6. The method comprises: and extending an effective period of the first flyable implement if the second flyable implement is detected within a target range of the first flyable implement.

2. The method of claim 1 .

7. the first flight trajectory is a straight-line trajectory, and the second flight trajectory is a circular trajectory that surrounds the first virtual object; 2. The method of claim 1 .

8. and controlling the first flyable implement to move along a second flight trajectory when a second flyable implement is detected within a target range of the first flyable implement, modifying a configuration of the first flyable implement based on the second flyable implement, the configuration including at least one of an entity shape or a flight special effect of the first flyable implement; and controlling the reconfigured first flyable implement to move along the second flight trajectory.

2. The method of claim 1 .

9. the step of changing the configuration of the first flyable implement based on the second flyable implement comprises: reserving the entity shape of the first flyable implement and assigning the flight special effects of the second flyable implement to the first flyable implement; or reserving the flight special effects of the first flyable implement and assigning the entity shape of the second flyable implement to the first flyable implement; or determining a target configuration based on the first flyable implement configuration and the second flyable implement configuration, and assigning the target configuration to the first flyable implement; 9. The method of claim 8.

10. and controlling the first flyable implement to move along a second flight trajectory when a second flyable implement is detected within a target range of the first flyable implement, if the second flyable implement is detected within a target range of the first flyable implement, controlling the first flyable implement to move along the second flight trajectory and canceling display of the second flyable implement.

2. The method of claim 1 .

11. 1. A flyable tool-based interaction device disposed on an electronic device, comprising: a creation module for creating a first flyable tool in the virtual scene in response to a release operation of a virtual skill by a first virtual object, the first flyable tool being associated with the virtual skill and the first virtual object belonging to a first faction; a first control module for controlling the first flyable implement to move along a first flight trajectory, the first flight trajectory being a trajectory determined based on the release operation; a second control module for controlling the first flyable implement to move along a second flight trajectory when a second flyable implement is detected within a target range of the first flyable implement, the second flyable implement being released by a second virtual object, the second virtual object belonging to a second faction, and the second flight trajectory being different from the first flight trajectory. An apparatus characterized in that

12. An electronic device including one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to realize the interaction method based on a flyable tool according to any one of claims 1 to 10. An electronic device characterized by:

13. A computer-readable storage medium having at least one computer program stored therein, the at least one computer program being loaded and executed by a processor to realize the interaction method based on a flyable tool according to any one of claims 1 to 10. A computer-readable storage medium comprising:

14. A computer program product, the computer program product including at least one computer program, the at least one computer program being loaded and executed by a processor to realize the interaction method based on a flyable tool according to any one of claims 1 to 10.

1. A computer program product comprising:

Images