Virtual motorcycle interaction control method and device, electronic equipment and storage medium

Abstract

The invention provides an interaction control method and device for a virtual motorcycle, electronic equipment and a storage medium, and the method comprises the steps: obtaining a current behavior state of a virtual character in response to a target interaction instruction triggered by a user; if the current behavior state is a non-driving state, performing validity verification on the generation space of the virtual motorcycle by taking the current position of the virtual character as a reference; if the validity verification is passed, instantiating the virtual motorcycle to the position of the virtual character, and establishing a driving binding relationship between the virtual character and the virtual motorcycle; if the current behavior state is the driving state, the binding relation between the virtual character and the virtual motorcycle is relieved, the virtual motorcycle is removed from the game scene, and meanwhile the virtual character is restored to the non-driving state. According to the method, real-time generation and driving binding of the virtual motorcycle can be realized through a single interaction instruction, redundant operation of searching a carrier and a running carrier is eliminated, and the continuity of game experience is effectively improved.

Description

Technical Field

[0001] This application relates to, but is not limited to, the fields of virtual interaction and computer graphics processing technology, and particularly to an interactive control method, device, electronic device, and storage medium for a virtual motorcycle. Background Technology

[0002] In open-world video games, to enrich the player's exploration experience and expand their range of movement, vast, seamless map environments are typically constructed, and highly mobile vehicles such as virtual motorcycles are provided for players to drive. When controlling virtual characters to travel long distances or traverse complex terrain, virtual motorcycles, with their speed advantage, often become the character's most frequently used mode of transportation.

[0003] In related technologies, the interaction logic of virtual motorcycles usually simulates the physical rules of the real world. That is, the vehicle is a separate entity that resides permanently at a specific coordinate in the scene. When the player gets off the vehicle to fight or explore away from the vehicle, if the player wants to drive again, he / she needs to control the character to move to the vehicle to trigger the getting-on animation. This causes the player to frequently experience the invalid time of searching for the vehicle while switching movement modes, which reduces the continuity and smoothness of the game experience. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application provides an interactive control method, device, electronic device, and storage medium for a virtual motorcycle, which can realize the instant generation and driving binding of a virtual motorcycle through a single interactive command, eliminating redundant operations of finding and running towards a vehicle, and effectively improving the continuity of the game experience.

[0005] In a first aspect, embodiments of this application provide an interactive control method for a virtual motorcycle, comprising: In response to the user's target interaction command, obtain the current behavioral state of the virtual character; If the current behavior state is a non-driving state, then the legality of the virtual motorcycle generation space is verified based on the current location of the virtual character. If the legality verification passes, the virtual motorcycle is instantiated at the location of the virtual character, and a driving binding relationship is established between the virtual character and the virtual motorcycle. If the current behavior state is driving, then the binding relationship between the virtual character and the virtual motorcycle is released, the virtual motorcycle is removed from the game scene, and the virtual character is restored to a non-driving state.

[0006] In some embodiments, the legality verification of the virtual motorcycle generation space includes: Obtain the configuration flag of the area where the virtual character is currently located, and determine the area permission detection result based on the configuration flag; Centered on the position coordinates of the virtual character, shape detectors are emitted around the virtual character. The space occupancy detection result is determined based on whether the shape detectors physically overlap with obstacle models in the game scene within a preset range. The size of the shape detectors matches the size of the collision box of the virtual motorcycle. If the area permission detection result indicates that generation is allowed, and the space occupancy detection result indicates that there is no physical overlap, the legality verification is deemed to have passed.

[0007] In some embodiments, instantiating the virtual motorcycle at the location of the virtual character and establishing a driving binding relationship between the virtual character and the virtual motorcycle includes: Obtain the current vertical support state of the virtual character: If the virtual character is in a ground-supported state, the generated posture of the virtual motorcycle is adjusted according to the ground normal so that its wheels are in contact with the ground; If the virtual character is in a state of falling from the air, the ground detection is ignored, and the virtual motorcycle is generated directly at the relative position of the virtual character's skeletal nodes.

[0008] In some embodiments, when the virtual character is in a state of falling from the air, establishing the driving binding relationship between the virtual character and the virtual motorcycle further includes: Obtain the instantaneous velocity vector of the virtual character when it responds to the target interaction command; Set the initial velocity vector of the virtual motorcycle to the instantaneous velocity vector; The root skeleton of the virtual character is attached to the driving mount point of the virtual motorcycle, and the physical controller of the virtual motorcycle is activated.

[0009] In some embodiments, unbinding the virtual character from the virtual motorcycle includes: Obtain the speed vector of the virtual motorcycle at the moment of unbinding; Disconnect the virtual character's control input mapping to the virtual motorcycle; The virtual character is separated from the virtual motorcycle, and the driving speed vector is transmitted to the virtual character according to a preset ratio as the initial inertial speed of the virtual character after leaving the vehicle.

[0010] In some embodiments, if the legality verification fails, the instantiation of the virtual motorcycle is aborted, and an interactive feedback message prohibiting summoning is output on the game screen.

[0011] In some embodiments, instantiating the virtual motorcycle at the location of the virtual character includes: Retrieve inactive virtual motorcycle objects from a pre-built object pool, switch the virtual motorcycle objects to an active state, and render them at the location of the virtual character; Removing the virtual motorcycle from the game scene includes: The current virtual motorcycle object is switched to an inactive state and returned to the object pool; wherein there is no preset cooldown time interval between the activation and deactivation operations of the virtual motorcycle object.

[0012] Secondly, embodiments of this application provide an interactive control device for a virtual motorcycle, comprising: The acquisition module is used to acquire the current behavioral state of the virtual character in response to the target interaction command triggered by the user; The verification module is used to verify the legality of the virtual motorcycle's generation space based on the current location of the virtual character if the current behavior state is a non-driving state. A module is established to instantiate the virtual motorcycle at the location of the virtual character if the legality verification passes, and to establish a driving binding relationship between the virtual character and the virtual motorcycle. The contact module is used to, if the current behavior state is driving, release the binding relationship between the virtual character and the virtual motorcycle, remove the virtual motorcycle from the game scene, and restore the virtual character to a non-driving state.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the interactive control method for a virtual motorcycle as described in any one of the embodiments of the first aspect of this application.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a program that is executed by a processor to implement the interactive control method for a virtual motorcycle as described in any one of the embodiments of the first aspect of this application.

[0015] The interactive control method for a virtual motorcycle according to the embodiments of this application has at least the following beneficial effects: The interactive control method for a virtual motorcycle according to an embodiment of this application includes: responding to a target interactive command triggered by a user, obtaining the current behavioral state of a virtual character; if the current behavioral state is a non-driving state, performing a legality check on the generation space of the virtual motorcycle based on the current location of the virtual character; if the legality check passes, instantiating the virtual motorcycle at the location of the virtual character and establishing a driving binding relationship between the virtual character and the virtual motorcycle; if the current behavioral state is a driving state, releasing the binding relationship between the virtual character and the virtual motorcycle, removing the virtual motorcycle from the game scene, and simultaneously restoring the virtual character to a non-driving state.

[0016] This application, by responding to user-triggered target interaction commands and obtaining the current behavioral state of the virtual character, can identify the player's interaction intentions in different scenarios. It achieves the reuse of both vehicle summoning and vehicle storage logic with a single button press, reducing the user's operational complexity. Then, by performing a legality check on the generated space based on the virtual character's current location when the current behavioral state is not driving, it can proactively avoid vehicle clipping and physical jamming issues caused by narrow terrain or obstacles, ensuring the safety and logical rationality of vehicle generation. Next, by directly instantiating the virtual motorcycle at the virtual character's location and establishing a driving binding relationship after successful verification, it enables instant vehicle boarding, eliminating the time cost of the character moving to the vehicle and triggering the boarding animation in traditional mechanisms. Finally, by unbinding the virtual motorcycle while driving and removing it from the scene, it achieves instant vehicle recycling and rapid restoration of the character's state, avoiding the occupation of map resources by idle vehicles and interference with subsequent summoning operations. Compared with existing technologies, this application can realize the instant generation and driving binding of virtual motorcycles through a single interactive command, eliminating redundant operations of finding and running towards vehicles, and effectively improving the continuity of the game experience.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 A flowchart of an optional interactive control method for a virtual motorcycle provided in an embodiment of this application; Figure 2 A flowchart of another optional interactive control method for a virtual motorcycle provided in an embodiment of this application; Figure 3 A flowchart of another optional interactive control method for a virtual motorcycle provided in an embodiment of this application; Figure 4 A flowchart of another optional interactive control method for a virtual motorcycle provided in an embodiment of this application; Figure 5 A flowchart of another optional interactive control method for a virtual motorcycle provided in an embodiment of this application; Figure 6 A schematic diagram of the interactive control device for a virtual motorcycle provided in an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0020] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, while "above," "below," "within," etc. are understood to include the stated number. Where "first" or "second" is mentioned, it is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the sequential relationship of the indicated technical features.

[0021] In the description of this application, it should be understood that the orientation descriptions, such as up, down, left, right, front, and back, are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0022] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0023] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setting," "installation," and "connection" should be interpreted broadly. Those skilled in the art can reasonably determine the specific meaning of the above terms in this application based on the specific content of the technical solution. Furthermore, the identification of specific steps in the following text does not imply a limitation on the order of steps or execution logic. The execution order and logic between each step should be understood and inferred from the content described in the embodiments.

[0024] In open-world video games, to enrich the player's exploration experience and expand their range of movement, vast, seamless map environments are typically constructed, and highly mobile vehicles such as virtual motorcycles are provided for players to drive. When controlling virtual characters to travel long distances or traverse complex terrain, virtual motorcycles, with their speed advantage, often become the character's most frequently used mode of transportation.

[0025] In related technologies, the interaction logic of virtual motorcycles usually simulates the physical rules of the real world. That is, the vehicle is a separate entity that resides permanently at a specific coordinate in the scene. When the player gets off the vehicle to fight or explore away from the vehicle, if the player wants to drive again, he / she needs to control the character to move to the vehicle to trigger the getting-on animation. This causes the player to frequently experience the invalid time of searching for the vehicle while switching movement modes, which reduces the continuity and smoothness of the game experience.

[0026] Based on this, this application, by responding to user-triggered target interaction commands and obtaining the current behavioral state of the virtual character, can identify the player's interaction intentions in different scenarios, realizing the reuse of both vehicle summoning and vehicle storage logic with a single button, reducing the user's operational complexity. Then, by performing a legality check on the generated space based on the virtual character's current location when the current behavioral state is not driving, the issues of vehicle clipping and physical jamming caused by narrow terrain or obstacles can be avoided in advance, ensuring the safety and logical rationality of vehicle generation. Next, by directly instantiating the virtual motorcycle at the virtual character's location and establishing a driving binding relationship after successful verification, instant vehicle boarding can be achieved, eliminating the time cost of the character moving to the vehicle and triggering the boarding animation in traditional mechanisms. Finally, by unbinding the virtual motorcycle while driving and removing it from the scene, the vehicle can be instantly recycled and the character's state quickly restored, avoiding the occupation of map resources by idle vehicles and interference with subsequent summoning operations. Compared with existing technologies, this application can realize the instant generation and driving binding of virtual motorcycles through a single interactive command, eliminating redundant operations of finding and running towards vehicles, and effectively improving the continuity of the game experience.

[0027] Please see Figure 1The present invention provides an interactive control method for a virtual motorcycle, which may include, but is not limited to, the following steps 101 to 104: Step 101: In response to the target interaction command triggered by the user, obtain the current behavioral state of the virtual character.

[0028] Step 102: If the current behavior state is non-driving state, then the legality of the virtual motorcycle generation space is verified based on the current location of the virtual character.

[0029] Step 103: If the legality verification passes, the virtual motorcycle is instantiated at the location of the virtual character, and a driving binding relationship is established between the virtual character and the virtual motorcycle.

[0030] Step 104: If the current behavior state is driving, then unbind the virtual character from the virtual motorcycle, remove the virtual motorcycle from the game scene, and restore the virtual character to a non-driving state.

[0031] In step 101 of some embodiments, it is first necessary to acquire the state of the player's input device in response to the target interaction command triggered by the user, and simultaneously acquire the current behavioral state of the virtual character. The target interaction command refers to a general request signal triggered by a single key (such as a specific shortcut key on a keyboard or a specific button on a gamepad). This signal does not distinguish between specific "getting on" or "getting off" intentions and is entirely dependent on the context for interpretation. The current behavioral state refers to the logical node that the virtual character is currently in in the state machine. For example, whether the character is in a non-driving state of "walking / running / standing" or in a driving state of "riding a motorcycle".

[0032] In step 102 of some embodiments, when it is determined that the current behavior state of the virtual character is non-driving, the generation prediction logic is initiated to perform a legality check on the generation space of the virtual motorcycle based on the current location of the virtual character. This process aims to confirm whether the environment in which the character is currently located has the physical space conditions to accommodate the motorcycle model. Legality checks typically involve scanning or querying the geometry around the character to exclude abnormal situations such as the character being close to a wall, in a narrow corridor, or at the edge of an invisible wall on the map, which are unsuitable for generating large vehicles, thus preventing clipping or physics system crashes caused by forced generation.

[0033] Please see Figure 2 In some embodiments, the step of validating the generation space of the virtual motorcycle in step 102 may also include, but is not limited to, steps 201 to 203.

[0034] Step 201: Obtain the configuration flag of the current region of the virtual character, and determine the region permission detection result based on the configuration flag.

[0035] Step 202: Using the virtual character's position coordinates as the center, launch shape detectors around the virtual character. Determine the space occupancy detection result based on whether the shape detectors physically overlap with obstacle models in the game scene within a preset range.

[0036] Step 203: If the area permission detection result indicates that generation is allowed and the space occupancy detection result indicates that there is no physical overlap, the legality verification is deemed to have passed.

[0037] In step 201 of some embodiments, rule determination based on static map data is first performed to obtain the configuration marker of the area where the virtual character is currently located, and the area permission detection result is determined based on the configuration marker. The configuration marker refers to metadata or tags pre-embedded in a specific area of ​​the map during the game level design stage, used to define the game rule attributes of that area (e.g., "indoor area", "story performance area", or "vehicle restricted area"). In this step, by reading the area attributes under the character's coordinates, it is determined whether the current scene allows the generation of vehicles. If the character is in a small indoor room or in a forced story process, the area permission detection result will be marked as prohibited, thereby blocking the summoning request.

[0038] In step 202 of some embodiments, dynamic physical environment detection is performed. Shape detectors are launched around the virtual character's location coordinates. The space occupancy detection result is determined based on whether the shape detectors physically overlap with obstacle models in the game scene within a preset range. A shape detector is an invisible physical detection box whose size parameters are set to match the size of the virtual motorcycle's physical collision box. The physics engine is used to detect whether the detector overlaps with walls, rocks, NPCs, or other objects in the scene, thereby determining whether the current location has physical space to accommodate the motorcycle.

[0039] In step 203 of some embodiments, a logical AND operation is performed on the detection results of the above two dimensions. If the area permission detection result indicates that generation is allowed and the space occupation detection result indicates that no physical overlap has occurred, the legality verification is determined to be passed, which ensures the rigor of the generation logic and prevents the vehicle from being generated in an illegal area or stuck inside the geometry due to the lack of a single condition.

[0040] Through steps 201 to 203 above, the embodiments of this application can effectively avoid serious bugs such as clipping, character freezing, and game logic collapse caused by forcibly generating vehicles in narrow, restricted, or plot-sensitive areas, ensuring the stability and scene adaptability of the virtual motorcycle instant summoning function.

[0041] In some embodiments, if the legality verification fails based on the aforementioned area permissions or spatial physics detection logic, an interruption mechanism will be immediately triggered to halt the instantiation process of the virtual motorcycle. This prevents serious technical malfunctions such as physics engine calculation errors, model freezing, or even program crashes caused by forcibly generating vehicles at illegal coordinates (such as inside walls, overlapping NPCs, or logically restricted areas). Along with the halting of the instantiation process, the UI (user interface) or audio module will be invoked to output interactive feedback information indicating that summoning is prohibited on the game screen. This feedback information can be visual (e.g., displaying a text prompt "Summoning is prohibited in the current area" in the center of the screen, changing the crosshair to a red prohibition icon, or playing a holographic error effect above the character's head) or auditory (e.g., playing a "Failed operation" beeping sound). This step aims to clearly convey to the player that the command was not executed because of logical limitations rather than input failure or a system bug, thereby guiding the player to move to an open area to try again, preventing confusion or repeated invalid operations due to uncertain system feedback.

[0042] In step 103 of some embodiments, once the legality verification is confirmed to be successful, the instantiation logic is immediately executed to instantiate the virtual motorcycle at the location of the virtual character and establish a driving binding relationship between the virtual character and the virtual motorcycle. Instantiation refers to dynamically creating or activating the motorcycle object at a specified coordinate in the game scene; the driving binding relationship refers to transferring control of the virtual character to the vehicle controller and attaching the character's model skeleton to the motorcycle's driver's seat mounting point. Through this step, the state switch between the character and the vehicle is forcibly completed without transition animation.

[0043] Please see Figure 3 In some embodiments, the step 103 of instantiating the virtual motorcycle at the location of the virtual character and establishing a driving binding relationship between the virtual character and the virtual motorcycle may also include, but is not limited to, steps 301 to 303.

[0044] Step 301: Obtain the current vertical support status of the virtual character.

[0045] Step 302: If the virtual character is in a ground-supported state, adjust the generated posture of the virtual motorcycle according to the ground normal so that its wheels are in contact with the ground.

[0046] Step 303: If the virtual character is in a state of falling from the air, ignore the ground detection and directly generate a virtual motorcycle at the relative position of the virtual character's skeletal nodes.

[0047] In step 301 of some embodiments, before executing the instantiation instruction, a rapid detection of the physical environment is first required to obtain the current vertical support state of the virtual character. The vertical support state is a Boolean value or an enumerated state used to identify whether the collider at the bottom of the character has physical contact with the ground model in the scene. It is usually determined by a short ray or spherical detection emitted downwards from the bottom of the character's feet. If a contact point is detected, it is determined to be a ground support state; if no collision feedback is detected within a preset distance, it is determined to be a suspended fall state.

[0048] In step 302 of some embodiments, when the determination result indicates that the virtual character is in a ground-supported state, a terrain adaptation algorithm is activated to adjust the generated posture of the virtual motorcycle according to the ground normal, so that its wheels are in contact with the ground. The ground normal refers to the direction vector perpendicular to the terrain surface under the character's feet. In this step, the vehicle is not simply generated in a horizontal posture (i.e., rotation angle of 0), but rather the alignment quaternion between the motorcycle chassis and the ground normal is calculated, so that the generated motorcycle can conform to the current slope or undulating terrain, avoiding visual clipping problems such as half of the vehicle being suspended in the air or the wheels sinking into the ground.

[0049] In step 303 of some embodiments, when the determination result is that the virtual character is in a state of falling in mid-air (e.g., the character is jumping off a cliff), the system will switch to the air generation mode, ignore ground detection, and directly generate a virtual motorcycle at the relative position of the virtual character's skeletal nodes. Specifically, the vehicle can be instantiated directly at a relatively fixed local coordinate offset (e.g., the crotch position) using the core skeleton of the character (such as the pelvis or hip node) as the parent anchor point. This step allows players to successfully summon vehicles even at extremely high altitudes above the ground.

[0050] Through steps 301 to 303 above, the embodiment of this application can automatically switch the instantiation logic according to the terrain context in which the character is located, which not only ensures the physical fit and visual realism when summoning on rugged slopes, but also realizes free summoning in a suspended state, greatly expanding the usage scenarios and spatial dimensions of virtual motorcycles.

[0051] Please see Figure 4 In some embodiments, when the virtual character is in a state of falling from the air, the step of establishing the driving binding relationship between the virtual character and the virtual motorcycle in step 103 may also include, but is not limited to, steps 401 to 403.

[0052] Step 401: Obtain the instantaneous velocity vector of the virtual character when responding to the target interaction command.

[0053] Step 402: Set the initial velocity vector of the virtual motorcycle to the instantaneous motion velocity vector.

[0054] Step 403: Attach the virtual character's root skeleton to the driving mount point of the virtual motorcycle and activate the virtual motorcycle's physical controller.

[0055] In step 401 of some embodiments, when a character is detected to be in an airborne state and a summoning command is triggered, data needs to be read from the physics engine within a very short instant of the logic frame to obtain the instantaneous motion velocity vector of the virtual character when responding to the target interaction command. The instantaneous motion velocity vector is a three-dimensional vector containing speed and direction, recording the physical motion state of the character at the moment the button is pressed. For example, if the character is sprinting down from a height, the vector will simultaneously contain a forward horizontal velocity component and a vertical falling component affected by gravity acceleration.

[0056] In step 402 of some embodiments, in conventional physics simulations, the default speed of newly generated objects is usually zero. This can cause a character falling at high speed to experience an unnatural mid-air braking or hovering phenomenon the moment they get on a motorcycle. This step, by forcibly overwriting the motorcycle's initial speed attribute, ensures that the motorcycle has a motion trend completely consistent with the character from the very first frame of its creation, thus guaranteeing the continuity of motion at the physical level.

[0057] In step 403 of some embodiments, while synchronizing speed, a switch between model and control is performed, attaching the virtual character's root skeleton to the virtual motorcycle's driving mount point and activating the virtual motorcycle's physics controller. The root skeleton typically refers to the character's pelvis or center of gravity node, and the driving mount point is a virtual anchor point preset on the motorcycle model. Simultaneously, the character's humanoid capsule collision is disabled, and the motorcycle's wheel physics simulation is enabled. Since the motorcycle has inherited its initial speed, after activating the physics controller, it will naturally continue flying along the character's original parabolic trajectory until the player inputs a new driving command or the character lands.

[0058] Through steps 401 to 403 above, this embodiment of the application obtains the instantaneous motion velocity vector of the virtual character when responding to the command, and forcibly synchronizes the initial velocity vector of the virtual motorcycle with the instantaneous motion velocity vector. This effectively solves the problem of physical jerking and visual discontinuity caused by summoning a static vehicle with an initial velocity of zero during high-speed movement or falling. It ensures that the virtual motorcycle can perfectly bear the inertial kinetic energy of the character at the moment of its generation in the air, realizing a smooth transition from free fall to vehicle gliding, and improving the smoothness and realism of aerial maneuvering gameplay.

[0059] In step 104 of some embodiments, if it is determined in step 101 that the current behavior state is already in a driving state, then the binding relationship between the virtual character and the virtual motorcycle is released, the virtual motorcycle is removed from the game scene, and the virtual character is restored to a non-driving state. Releasing the binding means cutting off the player's input control over the motorcycle and separating the character from the vehicle coordinate system; removing means immediately destroying the motorcycle instance or hiding it, making it disappear from the current scene both visually and physically. This logic ensures that the player does not need to worry about parking the vehicle after getting off, achieving a "use and go" interaction.

[0060] Please see Figure 5 In some embodiments, the step of unbinding the virtual character from the virtual motorcycle in step 104 may include, but is not limited to, steps 501 to 503.

[0061] Step 501: Obtain the speed vector of the virtual motorcycle at the moment of unbinding.

[0062] Step 502: Disconnect the virtual character's control input mapping to the virtual motorcycle.

[0063] Step 503: Separate the virtual character from the virtual motorcycle and transfer the driving speed vector to the virtual character according to a preset ratio as the initial inertial speed of the virtual character after leaving the vehicle.

[0064] In step 501 of some embodiments, when responding to the dismount command, the first step is to obtain the virtual motorcycle's velocity vector at the moment of unbinding in the last frame before the interruption. This vector not only contains the motorcycle's current scalar rate but also records its direction of motion in three-dimensional space. For example, when the player drives the motorcycle at high speed off a ramp and triggers dismount in mid-air, this step captures composite velocity data with significant horizontal forward and vertical upward components, providing a physical basis for the subsequent kinetic energy inheritance of the character.

[0065] In step 502 of some embodiments, the control input mapping between the virtual character and the virtual motorcycle is severed. Control input mapping refers to an intermediate protocol that converts signals from the player's physical input devices (such as gamepad joysticks or keyboard buttons) into in-game vehicle torque or steering angle. In this step, the input target is switched from the motorcycle controller back to the character controller or set to an empty state, ensuring that at the moment the dismounting action begins, subsequent player actions (such as movement or attack) do not mistakenly trigger the motorcycle's acceleration or steering, preventing the vehicle from going out of control.

[0066] In step 503 of some embodiments, the virtual character is separated from the virtual motorcycle, and the driving speed vector is transferred to the virtual character according to a preset ratio as the initial inertial speed of the virtual character after detaching from the vehicle. Specifically, the hierarchical relationship between the character model and the motorcycle attachment point is removed, and an impulse is applied to the character component. The magnitude of this impulse is usually set to a certain percentage of the original speed of the motorcycle (e.g., 80% or 100%), which prevents the character from falling vertically after detaching from the vehicle, but instead propels it forward a distance along the original trajectory of the motorcycle.

[0067] Through steps 501 to 503 described above, this embodiment of the application extracts the instantaneous velocity of the vehicle and converts it into the initial momentum of the character, achieving a physical interaction feedback that conforms to common sense. This mechanism effectively solves the awkwardness of sudden stops upon exiting a vehicle in traditional games, ensuring that the character can obtain natural inertial displacement when performing the exit operation while driving at high speed, thereby supporting actions such as "jumping out of the vehicle" and "separating in mid-air," and ensuring visual smoothness and physical coherence when switching from driving mode to walking or combat mode.

[0068] In some embodiments, the step of instantiating a virtual motorcycle at the location of the virtual character may include: Retrieve inactive virtual motorcycle objects from a pre-built object pool, activate the virtual motorcycle objects, and render them at the location of the virtual character.

[0069] Specifically, an object pool containing several virtual motorcycle objects can be pre-built during the game loading phase. These objects reside in memory but are in an inactive state (i.e., invisible and not involved in physics calculations). When responding to a summoning command, the system does not perform a high-overhead memory allocation operation to create a new vehicle. Instead, it directly retrieves an idle virtual motorcycle object from the pre-built object pool, teleports its coordinates to the location of the virtual character, and switches the object to an active state.

[0070] Removing the virtual motorcycle from the game scene includes: Switch the current virtual motorcycle object to an inactive state and return the virtual motorcycle to the object pool; there is no preset cooldown time interval between the activation and deactivation operations of the virtual motorcycle object.

[0071] The process of removing the virtual motorcycle from the game scene also follows the principle of resource recycling rather than destruction. When the player gets off the motorcycle and triggers the hiding logic, the current virtual motorcycle object is switched to an inactive state, that is, its mesh renderer and physical collider are turned off, and it is marked as idle and returned to the object pool to await the next call. During this process, there is no preset cooldown time interval between the activation and deactivation operations of the virtual motorcycle object. This means that the system allows players to trigger the summon-hide-resummon operation sequence continuously in a very short period of time, further enhancing the freedom of driving interaction.

[0072] Please see Figure 6 This application also provides an interactive control device for a virtual motorcycle, which can implement the above-mentioned interactive control method for a virtual motorcycle, including: The acquisition module is used to acquire the current behavioral state of the virtual character in response to the target interaction command triggered by the user; The verification module is used to verify the legality of the virtual motorcycle's generation space based on the virtual character's current location if the current behavior state is not driving. A module is created to instantiate the virtual motorcycle at the location of the virtual character if the legality verification passes, and to establish a driving binding relationship between the virtual character and the virtual motorcycle. The contact module is used to remove the virtual character from the virtual motorcycle if the current behavior state is driving, and remove the virtual motorcycle from the game scene, while restoring the virtual character to a non-driving state.

[0073] The interactive control method for a virtual motorcycle according to an embodiment of this application includes: responding to a target interactive command triggered by a user, obtaining the current behavioral state of a virtual character; if the current behavioral state is a non-driving state, performing a legality check on the generation space of the virtual motorcycle based on the current location of the virtual character; if the legality check passes, instantiating the virtual motorcycle at the location of the virtual character and establishing a driving binding relationship between the virtual character and the virtual motorcycle; if the current behavioral state is a driving state, releasing the binding relationship between the virtual character and the virtual motorcycle, removing the virtual motorcycle from the game scene, and simultaneously restoring the virtual character to a non-driving state.

[0074] This application, by responding to user-triggered target interaction commands and obtaining the current behavioral state of the virtual character, can identify the player's interaction intentions in different scenarios. It achieves the reuse of both vehicle summoning and vehicle storage logic with a single button press, reducing the user's operational complexity. Then, by performing a legality check on the generated space based on the virtual character's current location when the current behavioral state is not driving, it can proactively avoid vehicle clipping and physical jamming issues caused by narrow terrain or obstacles, ensuring the safety and logical rationality of vehicle generation. Next, by directly instantiating the virtual motorcycle at the virtual character's location and establishing a driving binding relationship after successful verification, it enables instant vehicle boarding, eliminating the time cost of the character moving to the vehicle and triggering the boarding animation in traditional mechanisms. Finally, by unbinding the virtual motorcycle while driving and removing it from the scene, it achieves instant vehicle recycling and rapid restoration of the character's state, avoiding the occupation of map resources by idle vehicles and interference with subsequent summoning operations. Compared with existing technologies, this application can realize the instant generation and driving binding of virtual motorcycles through a single interactive command, eliminating redundant operations of finding and running towards vehicles, and effectively improving the continuity of the game experience.

[0075] Reference Figure 7 , Figure 7 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 702 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 702 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 702 and is called and executed by the processor 701 to execute the interactive control method of the virtual motorcycle in the embodiments of this application. The input / output interface 703 is used to implement information input and output; The communication interface 704 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.). Bus 705 transmits information between various components of the device (e.g., processor 701, memory 702, input / output interface 703, and communication interface 704); The processor 701, memory 702, input / output interface 703, and communication interface 704 are connected to each other within the device via bus 705.

[0076] This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the interactive control method for the virtual motorcycle described above.

[0077] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0078] It should be understood that in this disclosure, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0079] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0080] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0083] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0084] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0085] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. An interactive control method for a virtual motorcycle, characterized in that, include: In response to the user's target interaction command, obtain the current behavioral state of the virtual character; If the current behavior state is a non-driving state, then the legality of the virtual motorcycle generation space is verified based on the current location of the virtual character. If the legality verification passes, the virtual motorcycle is instantiated at the location of the virtual character, and a driving binding relationship is established between the virtual character and the virtual motorcycle. If the current behavior state is driving, then the binding relationship between the virtual character and the virtual motorcycle is released, the virtual motorcycle is removed from the game scene, and the virtual character is restored to a non-driving state.

2. The interactive control method for a virtual motorcycle according to claim 1, characterized in that, The legality verification of the virtual motorcycle generation space includes: Obtain the configuration flag of the area where the virtual character is currently located, and determine the area permission detection result based on the configuration flag; Centered on the position coordinates of the virtual character, shape detectors are emitted around the virtual character. The space occupancy detection result is determined based on whether the shape detectors physically overlap with obstacle models in the game scene within a preset range. The size of the shape detectors matches the size of the collision box of the virtual motorcycle. If the area permission detection result indicates that generation is allowed, and the space occupancy detection result indicates that there is no physical overlap, the legality verification is deemed to have passed.

3. The interactive control method for a virtual motorcycle according to claim 1, characterized in that, The step of instantiating the virtual motorcycle at the location of the virtual character and establishing a driving binding relationship between the virtual character and the virtual motorcycle includes: Obtain the current vertical support state of the virtual character: If the virtual character is in a ground-supported state, the generated posture of the virtual motorcycle is adjusted according to the ground normal so that its wheels are in contact with the ground; If the virtual character is in a state of falling from the air, the ground detection is ignored, and the virtual motorcycle is generated directly at the relative position of the virtual character's skeletal nodes.

4. The interactive control method for a virtual motorcycle according to claim 3, characterized in that, When the virtual character is in a state of falling from the air, establishing the driving binding relationship between the virtual character and the virtual motorcycle also includes: Obtain the instantaneous velocity vector of the virtual character when it responds to the target interaction command; Set the initial velocity vector of the virtual motorcycle to the instantaneous velocity vector; The root skeleton of the virtual character is attached to the driving mount point of the virtual motorcycle, and the physical controller of the virtual motorcycle is activated.

5. The interactive control method for a virtual motorcycle according to claim 1, characterized in that, The process of unbinding the virtual character from the virtual motorcycle includes: Obtain the speed vector of the virtual motorcycle at the moment of unbinding; Disconnect the virtual character's control input mapping to the virtual motorcycle; The virtual character is separated from the virtual motorcycle, and the driving speed vector is transmitted to the virtual character according to a preset ratio as the initial inertial speed of the virtual character after leaving the vehicle.

6. The interactive control method for a virtual motorcycle according to claim 1, characterized in that, If the sexuality check fails, the instantiation of the virtual motorcycle is aborted, and an interactive feedback message prohibiting summoning is output on the game screen.

7. The interactive control method for a virtual motorcycle according to claim 4, characterized in that, The step of instantiating the virtual motorcycle at the location of the virtual character includes: Retrieve inactive virtual motorcycle objects from a pre-built object pool, switch the virtual motorcycle objects to an active state, and render them at the location of the virtual character; Removing the virtual motorcycle from the game scene includes: The current virtual motorcycle object is switched to an inactive state and returned to the object pool; wherein there is no preset cooldown time interval between the activation and deactivation operations of the virtual motorcycle object.

8. An interactive control device for a virtual motorcycle, characterized in that, The device includes: The acquisition module is used to acquire the current behavioral state of the virtual character in response to the target interaction command triggered by the user; The verification module is used to verify the legality of the virtual motorcycle's generation space based on the current location of the virtual character if the current behavior state is a non-driving state. A module is established to instantiate the virtual motorcycle at the location of the virtual character if the legality verification passes, and to establish a driving binding relationship between the virtual character and the virtual motorcycle. The contact module is used to, if the current behavior state is driving, release the binding relationship between the virtual character and the virtual motorcycle, remove the virtual motorcycle from the game scene, and restore the virtual character to a non-driving state.

9. An electronic device, characterized in that, include: The system includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the interactive control method for a virtual motorcycle as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a program that is executed by a processor to implement the interactive control method for a virtual motorcycle as described in any one of claims 1 to 7.

Images