Vehicle processing method and apparatus in virtual scene, electronic device, computer-readable storage medium, and computer program product

Abstract

A vehicle processing method and apparatus in a virtual scene, an electronic device, a computer readable storage medium, and a computer program product. The method comprises: displaying in a virtual scene a virtual vehicle carrying a first virtual object; and in response to the first virtual object being located in a first area of the virtual scene, controlling the virtual vehicle to move in a first movement mode adapted to the first area, wherein the type of the first area is any one of the following: an air area, a ground area, and a water surface area.

Description

Virtual scene vehicle processing methods, devices, electronic devices, computer-readable storage media and computer program products

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202411671733.8, filed on November 20, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of Internet technology, and in particular to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for processing virtual scene vehicles. Background Technology

[0004] Display technologies based on graphics processing hardware have expanded the channels for perceiving the environment and acquiring information. In particular, virtual scene display technologies can realize diverse interactions between virtual objects controlled by players or artificial intelligence (AI) according to actual application needs. They have various typical application scenarios. For example, in virtual scenes such as games, they can simulate the real combat process between virtual objects.

[0005] Taking open-world games as an example, in related technologies, players' additional movement ability is usually achieved through virtual vehicles with a single function. For movement in different scenarios, players usually need to frequently switch virtual vehicles. However, frequently switching virtual vehicles will constantly trigger the loading and unloading process of resources, which will undoubtedly consume a lot of memory resources and may also put a lot of pressure on the server, thus causing the game to lag. Summary of the Invention

[0006] This application provides a vehicle processing method, apparatus, electronic device, computer-readable storage medium, and computer program product for virtual scenes, which can provide multiple mobility modes for exploring virtual scenes, fully covering the land, sea, and air of virtual scenes, thereby greatly improving mobility efficiency and operational flexibility, while also saving memory resources of terminal devices and servers.

[0007] The technical solution of this application embodiment is implemented as follows:

[0008] This application provides a vehicle processing method for a virtual scene, executed by an electronic device, including:

[0009] Display the virtual vehicle carrying the first virtual object in the virtual scene;

[0010] In response to the first virtual object being located in a first region of the virtual scene, the virtual vehicle is controlled to move in a first movement mode adapted to the first region, wherein the type of the first region is any one of the following: an air region, a ground region, and a water region.

[0011] This application provides a vehicle processing device for a virtual scene, comprising:

[0012] The display module is configured to display a virtual vehicle carrying the first virtual object in a virtual scene;

[0013] The control module is configured to control the virtual vehicle to move in a first movement mode adapted to the first area in response to the first virtual object being in a first area of ​​the virtual scene, wherein the type of the first area is any one of the following: an air area, a ground area, and a water area.

[0014] This application provides an electronic device, including:

[0015] Memory is used to store executable instructions for a computer;

[0016] The processor, when executing computer-executable instructions stored in the memory, implements the vehicle processing method for the virtual scene provided in the embodiments of this application.

[0017] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the vehicle processing method for a virtual scene provided in this application.

[0018] This application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the vehicle processing method for a virtual scene provided in this application.

[0019] The embodiments of this application have the following beneficial effects:

[0020] By setting multiple movement modes for virtual vehicles to fully cover land, sea, and air in the virtual scene, players can use virtual vehicles to glide on the ground, surf on the water, or glide in the air. This allows for automatic and seamless switching between different scenes, greatly improving movement efficiency and operational flexibility. At the same time, the resources of the same virtual vehicle only need to be loaded once when the game starts. When moving in different scenes later, there is no need to frequently unload and load new vehicle models, textures, and other resources, thereby reducing the memory usage of terminal devices and servers, as well as the pressure on data processing, and avoiding slow game performance due to excessive data volume. Attached Figure Description

[0021] Figure 1 is a schematic diagram of the architecture of the vehicle processing system 100 for a virtual scene provided in an embodiment of this application;

[0022] Figure 2 is a schematic diagram of the structure of the electronic device 500 provided in an embodiment of this application;

[0023] Figure 3 is a first flowchart of the vehicle processing method for a virtual scene provided in an embodiment of this application;

[0024] Figure 4 is a second flowchart of the vehicle processing method for a virtual scene provided in an embodiment of this application;

[0025] Figure 5 is a schematic diagram of the third process of the vehicle processing method in the virtual scene provided in the embodiment of this application;

[0026] Figure 6A is a schematic diagram of the first application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application;

[0027] Figure 6B is a schematic diagram of a second application scenario of the vehicle processing method for virtual scenes provided in the embodiments of this application;

[0028] Figure 6C is a schematic diagram of a third application scenario of the vehicle processing method for virtual scenes provided in the embodiments of this application;

[0029] Figure 6D is a schematic diagram of the fourth application scenario of the vehicle processing method for virtual scenes provided in the embodiments of this application;

[0030] Figure 6E is a schematic diagram of the fifth application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application;

[0031] Figure 6F is a schematic diagram of the sixth application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application;

[0032] Figure 6G is a schematic diagram of the seventh application scenario of the vehicle processing method for virtual scenes provided in the embodiments of this application;

[0033] Figure 6H is a schematic diagram of the eighth application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application;

[0034] Figure 6I is a schematic diagram of the ninth application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application;

[0035] Figure 6J is a schematic diagram of the tenth application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application;

[0036] Figure 6K is a schematic diagram of the eleventh application scenario of the vehicle processing method for virtual scenes provided in the embodiments of this application;

[0037] Figure 7 is a schematic diagram of the principle of the vehicle processing method in the virtual scene provided in the embodiment of this application;

[0038] Figure 8 is a schematic diagram of the skateboard state transition provided in an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0041] It is understood that in the embodiments of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0042] In the following description, the terms “first, second, ...” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first, second, ...” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0044] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0045] 1) Responding to: used to indicate the conditions or states on which the operation is performed depends. When the conditions or states on which it depends are met, one or more operations can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0046] 2) Human-Computer Interface (HCI): This refers to an interface used to provide human-computer interaction functions or to display information in virtual scenes. Examples of HCI interfaces include Graphical User Interface (GUI), Augmented Reality (AR) interfaces, Virtual Reality (VR) interfaces, Voice User Interface (VUI), Interactive Projection Interface (using projection technology to display information on a flat surface), Eye-tracking Interface (controlling the interface by detecting the user's gaze), Holographic Interface (a three-dimensional hologram formed by projecting images using holographic projection technology, allowing viewing of stereoscopic images without special glasses), Multimodal Interface (an interface combining multiple interaction methods, such as tactile, visual, and auditory interfaces), and Brain-Machine Interface (BMI), etc.

[0047] 3) Virtual Scene: This refers to the scene displayed (or provided) by the application when it runs on the terminal device. This scene can be a simulation of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. A virtual scene can be any of a two-dimensional, 2.5-dimensional, or three-dimensional virtual scene; this application does not limit the dimension of the virtual scene. For example, a virtual scene may include the sky, land, ocean, etc., and the land may include environmental elements such as deserts and cities. Users can control virtual objects to move within this virtual scene.

[0048] 4) Virtual Objects: These are interactive representations of people and objects within a virtual scene, or movable objects within the virtual scene. These movable objects can be virtual characters, virtual animals, anime characters, etc., such as people or animals displayed in a virtual scene. For example, a virtual object can be a virtual avatar representing the user within a virtual scene. A virtual scene can include multiple virtual objects, each with its own shape and volume, occupying a portion of the space within the virtual scene.

[0049] 5) Virtual vehicles: Objects used for transportation in a virtual scene, controlled by the user or robot account, which can assist virtual objects to move quickly in the virtual scene, such as virtual skateboards, virtual hang gliders, etc.

[0050] 6) Cloud Gaming: Also known as Gaming on Demand, this involves deploying a game program on a server and running an instance of the game program (referred to as a game instance). The game instance sends the game data output during its operation to the user's browser page. The page uses the browser's media components to decode the game data and renders the real-time game screen based on the decoding results. When the page detects user actions in the game screen, it reports this to the game instance running on the server. Upon receiving the game data generated by the game instance in response to the action, the page repeats the decoding and rendering process, thus displaying the changes in the game screen based on the user's actions.

[0051] In other words, cloud gaming is an online gaming technology based on cloud computing. Cloud gaming technology enables thin clients with relatively limited graphics processing and data processing capabilities to run high-quality games. In a cloud gaming scenario, the game does not run on the user's terminal (e.g., the player's gaming terminal), but rather on a cloud server. The cloud server renders the game scene as an audio and video stream, which is then transmitted to the user's terminal via the network. Therefore, the user's terminal does not need powerful graphics processing and data processing capabilities; it only needs basic streaming media playback capabilities and the ability to receive player input commands and send them to the cloud server.

[0052] 7) Open World Game: This is a game genre that provides players with a vast, highly free virtual environment where they can freely explore and act, rather than simply following a pre-set storyline or quest path. Open world games typically feature the following characteristics: free exploration, a large map, diverse quests, and non-linear storylines.

[0053] Taking open-world games as an example, related technologies typically employ different virtual vehicles for different mobility abilities. For instance, players can fly using gliders or walk on mounts. In other words, additional player mobility is usually achieved through single-function vehicles, resulting in a relatively simplistic control scheme. Players often rely on a single button press or specific terrain triggers for automatic movement, lacking a sense of responsiveness. Furthermore, the solutions provided by these technologies do not support flexible switching between multiple movement states. When moving in different scenarios, players often need to frequently switch vehicles, causing a sense of interruption in movement or controls. Additionally, the vehicle system and combat system in these solutions are disconnected, hindering smooth and rapid switching between combat and movement.

[0054] In view of this, embodiments of this application provide a vehicle processing method, apparatus, electronic device, computer-readable storage medium, and computer program product for virtual scenes, which can provide multiple movement modes for exploring virtual scenes, comprehensively covering land, sea, and air in virtual scenes, thereby greatly improving movement efficiency and operational flexibility. Furthermore, the technical solution provided by embodiments of this application also possesses spatial movement skills such as jetting, jumping, and double jumping (i.e., being able to perform a second jump during the first jump), and integrates combat capabilities such as shooting and flying kicks, allowing players to both remotely pull enemies and quickly engage in close combat while exploring virtual scenes, balancing high mobility and combat performance. The electronic device provided by embodiments of this application will be described below. The electronic device provided by embodiments of this application can be implemented as a terminal device (corresponding to a single-player game application), or implemented collaboratively by a terminal device and a server (corresponding to an online game application). The following description uses the vehicle processing method for virtual scenes provided by embodiments of this application, implemented collaboratively by a server and a terminal device, as an example.

[0055] Before introducing the architecture of the vehicle processing system for virtual scenes provided in this application embodiment, the game modes involved in this application embodiment will first be introduced. For the solution implemented collaboratively by terminal devices and servers, two main game modes are involved: local game mode and cloud game mode. In local game mode, the terminal device and server collaboratively run the game processing logic. The operation commands input by the player on the terminal device are partly processed by the terminal device's game logic and partly by the server's game logic. Furthermore, the game logic processed by the server is often more complex and requires more computing power. In cloud game mode, the game logic is entirely processed by the server (e.g., a cloud server), and the cloud server renders the game scene data into audio and video streams, which are then transmitted to the terminal device for display via the network. In other words, the terminal device only needs basic streaming media playback capabilities and the ability to obtain player operation commands and send them to the server.

[0056] The architecture of the vehicle processing system for virtual scenes provided in the embodiments of this application will be described below.

[0057] For example, referring to Figure 1, Figure 1 is a schematic diagram of the architecture of a virtual scene vehicle processing system 100 provided in an embodiment of this application. As shown in Figure 1, the virtual scene vehicle processing system 100 includes: a server 200 (e.g., a game backend server), a network 300, and a terminal device 400. The network 300 can be a local area network or a wide area network, or a combination of both. The terminal device 400 is a terminal device associated with the player. A client 410 runs on the terminal device 400. The client 410 can be various types of game clients, such as open-world game clients, role-playing game clients, shooting game clients, and browsers.

[0058] In some embodiments, taking client 410 as an open-world game client as an example, a virtual scene can be displayed in the human-computer interaction interface of client 410. A virtual vehicle (e.g., a virtual skateboard) carrying a first virtual object (e.g., a game character A controlled by the player) can be displayed in the virtual scene. For example, a game character A standing on a virtual skateboard can be displayed in the virtual scene. Then, when client 410 detects that the first virtual object is currently in a first area of ​​the virtual scene, it can control the virtual vehicle to move in a first movement mode adapted to the first area. The type of the first area can be any of the following: an air area, a ground area, and a water area, for example... For example, when client 410 detects that game character A is currently in the air area of ​​the virtual scene, it can control the virtual vehicle carrying game character A to fly in the air area; when client 410 detects that game character A is currently in the ground area of ​​the virtual scene, it can control the virtual vehicle carrying game character A to glide on the ground area; when client 410 detects that game character A is currently in the water area of ​​the virtual scene, it can control the virtual vehicle carrying game character A to surf on the water area. In this way, the virtual vehicle can fully cover the land, sea and air of the virtual scene, realizing automatic and seamless switching between different scenes, thereby greatly improving movement efficiency and operational flexibility.

[0059] It should be noted that the virtual scene in the vehicle processing method of the virtual scene provided in this application embodiment can be entirely based on the output of the terminal device, or based on the collaborative output of the terminal device and the server. For example, it can rely entirely on the graphics processing hardware computing power of the terminal device 400 shown in Figure 1 to complete the relevant data calculation and output of the virtual scene. The types of graphics processing hardware include central processing units (CPUs) and graphics processing units (GPUs). For example, when forming visual perception of the virtual scene, the terminal device 400 calculates the data required for display through graphics computing hardware, and completes the loading, parsing and rendering of the display data. The graphics output hardware outputs video frames that can form visual perception of the virtual scene. For example, it presents two-dimensional video frames on the display screen of a smartphone, or projects video frames that achieve a three-dimensional display effect onto the lenses of augmented reality / virtual reality glasses. In addition, in order to enrich the perception effect, the terminal device 400 can also use different hardware to form one or more of auditory perception, tactile perception, motion perception and taste perception.

[0060] Of course, the computing power of server 200 can also be used to complete the virtual scene calculation and output the virtual scene to terminal device 400. For example, taking the visual perception of forming a virtual scene as an example, server 200 calculates the display data (such as scene data) related to the virtual scene and sends it to terminal device 400 through network 300. Terminal device 400 relies on graphics computing hardware to complete the loading, parsing and rendering of the calculated display data, and relies on graphics output hardware to output the virtual scene to form a visual perception. For example, two-dimensional video frames can be presented on the display screen of a smartphone, or video frames that achieve a three-dimensional display effect can be projected onto the lenses of augmented reality / virtual reality glasses. As for the perception of the form of the virtual scene, it can be understood that the corresponding hardware output of terminal device 400 can be used, such as using a microphone to form auditory perception, using a vibrator to form tactile perception, and so on.

[0061] Furthermore, it should be noted that the server 200 in Figure 1 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal device 400 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, in-vehicle terminal, etc., but is not limited to these. The terminal device 400 and the server 200 can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0062] In some embodiments, the terminal device can also implement the vehicle processing method for the virtual scene provided in this application embodiment by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run, such as open-world game APPs; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0063] The structure of the electronic device provided in the embodiments of this application will be described below. Taking the electronic device as a terminal device as an example, referring to FIG2, FIG2 is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application. The electronic device 500 shown in FIG2 includes: at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together through a bus system 540. It can be understood that the bus system 540 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, all buses are labeled as bus system 540 in FIG2.

[0064] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0065] User interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0066] The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 550 may optionally include one or more storage devices physically located away from the processor 510.

[0067] The memory 550 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 550 described in this application embodiment is intended to include any suitable type of memory.

[0068] In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0069] Operating system 551 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0070] The network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0071] Presentation module 553 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., a display screen, a speaker, etc.) associated with user interface 530;

[0072] The input processing module 554 is used to detect and translate one or more user inputs or interactions from one or more input devices 532.

[0073] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 shows a vehicle processing apparatus 555 for a virtual scene stored in memory 550. This apparatus can be software in the form of programs and plugins, including the following software modules: a display module 5551, a control module 5552, and a detection module 5553. These modules are logically related and can therefore be arbitrarily combined or further separated according to their implemented functions. It should be noted that, for ease of explanation, all the above modules are shown at once in Figure 2. However, this should not be construed as excluding the possibility that the vehicle processing apparatus 555 for the virtual scene may only include the display module 5551 and the control module 5552. The functions of each module will be described below.

[0074] The vehicle processing method for virtual scenes provided in this application will be specifically described below with reference to the exemplary application and implementation of the terminal device provided in the embodiments of this application.

[0075] For example, see Figure 3, which is a first flowchart of the vehicle processing method for a virtual scene provided in an embodiment of this application. The steps shown in Figure 3 will be described in conjunction with the steps shown in Figure 3.

[0076] It should be noted that the method shown in Figure 3 can be executed by various forms of computer programs running on the terminal device, and is not limited to a client. For example, it can also be the operating system, software module, script, and applet mentioned above. Therefore, the client example used below should not be considered as a limitation on the embodiments of this application. In addition, for the sake of convenience, no specific distinction will be made between the terminal device and the client running on the terminal device below.

[0077] In step 101, a virtual vehicle carrying the first virtual object is displayed in the virtual scene.

[0078] Here, the first virtual object can be a game character A controlled by the current player (e.g., player 1) in a virtual scene. Virtual vehicles can include virtual skateboards, virtual gliders, and virtual mounts. For example, if the virtual vehicle is a virtual skateboard, the game character A standing on the virtual skateboard can be displayed in the virtual scene. Or if the virtual vehicle is a virtual mount, the game character A riding the virtual mount can be displayed in the virtual scene.

[0079] In some embodiments, step 101 can be implemented as follows: displaying a virtual scene, wherein the virtual scene includes a first virtual object; in response to a vehicle summoning operation (e.g., a click operation on a vehicle summoning button displayed on the screen, or a click operation on a specific key on the keyboard), maintaining the current motion state of the first virtual object, and controlling a virtual vehicle to appear at the location of the first virtual object and carry the first virtual object.

[0080] For example, taking the first virtual object as a game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, the game character A can be displayed in a third-person perspective in the virtual scene. Player 1 can control the game character A to summon the virtual skateboard while it is stationary, moving, or falling. For example, when player 1 clicks the "Summon Skateboard" button (which could be a virtual button on the screen or the "T" key on the keyboard), the current movement state of the game character A can be maintained. For example, assuming player 1 clicks the "Summon Skateboard" button while the game character A is moving, the game character A can continue to move during the process of summoning the virtual skateboard. Assuming player 1 clicks the "Summon Skateboard" button while game character A is in a standby state, during the summoning of the virtual skateboard, player 1 can control game character A to remain in a standby state. Then, player 1 can control the virtual skateboard to appear under game character A's feet (for example, player 1 can control the virtual skateboard to move from a distance to game character A's feet, or control multiple skateboard fragments to form a complete virtual skateboard under game character A's feet), and carry game character A. In this way, when the game character summons the virtual skateboard, by preserving the game character's original movement state, the summoning process of the virtual skateboard can be more naturally integrated into the character's movement state, thus providing players with a more realistic and smooth operating experience.

[0081] In other embodiments, following the examples above, the control of the virtual vehicle appearing at the location of the first virtual object can be achieved in the following ways: in response to the first virtual object being in a moving state, a first animation (e.g., an animation of "summoning a vehicle while moving") is played, and after the first animation finishes playing, the virtual vehicle is controlled to appear at the location of the first virtual object, wherein the first animation can be used to represent the first virtual object in a moving state summoning a virtual vehicle; in response to the first virtual object being in a stationary state (e.g., a standby state), a second animation (e.g., an animation of "summoning a vehicle while standing still") is played, and after the second animation finishes playing, the virtual vehicle is controlled to appear at the location of the first virtual object (e.g., under the feet of the first virtual object), wherein the second animation can be used to represent the first virtual object in a stationary state summoning a virtual vehicle.

[0082] For example, taking the first virtual object as game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, when player 1 clicks the "Summon Skateboard" button while game character A is moving, an animation of "Summoning Skateboard While Moving" will play, and after the animation finishes, the virtual skateboard will appear under the feet of game character A. When player 1 clicks the "Summon Skateboard" button while game character A is stationary, an animation of "Summoning Skateboard While Stationary" will play, and after the animation finishes, the virtual skateboard will appear under the feet of game character A. In other words, when the player controls the game character in different states to summon the skateboard, different visual feedback can be presented, making it easier for the player to understand and further enhancing the player's gaming experience.

[0083] In step 102, in response to the first virtual object being in a first area of ​​the virtual scene, the virtual vehicle is controlled to move in a first movement mode adapted to the first area.

[0084] Here, the first area can be any of the following: an air area, a ground area, or a water area. For example, taking a virtual skateboard as a virtual vehicle, the first virtual object can fly in the air area of ​​the virtual scene, surf in the water area, or glide on the ground area using the virtual skateboard. That is, the movement mode of the virtual vehicle in the air area can be flying, the movement mode in the water area can be surfing, and the movement mode in the ground area can be gliding. In other words, the embodiments of this application can comprehensively cover the air, land, and sea in the virtual scene by setting multiple movement modes for the virtual skateboard. When entering the water area, the skateboard can automatically trigger surfing mode deformation (e.g., the bottom of the board unfolds a floating board structure), while generating water ripples, water splash particle effects, and playing the sound effect of waves hitting the ground; when entering the air area, the skateboard can activate flight thruster effects (e.g., tail jet airflow) and weaken the ground shadow rendering to conform to the air lighting logic, while also playing the low hum of the thruster. By triggering this multi-sensory feedback synchronously, players can intuitively perceive the matching degree between the current movement mode and the scene through sight and hearing, which can greatly enhance the immersion of the virtual scene.

[0085] In some embodiments, referring to FIG4, FIG4 is a second flowchart of the vehicle processing method for a virtual scene provided in the embodiments of this application. As shown in FIG4, step 102 shown in FIG3 can be implemented by steps 1021 and 1022 shown in FIG4, and will be described in conjunction with the steps shown in FIG4.

[0086] In step 1021, when the first virtual object is in the air area of ​​the virtual scene, during the period when no movement trigger operation is received for the virtual vehicle, the virtual vehicle is controlled to switch from the first form to the second form and fly in the air area at the first flight speed.

[0087] Here, the second form and the first form are different forms used to carry the first virtual object. For example, in the first form, the first virtual object can stand on the virtual vehicle; in the second form, the first virtual object can sit on the virtual vehicle.

[0088] For example, taking the first virtual object as a game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, when player 1 controls the virtual skateboard carrying game character A (for example, game character A could be standing on the virtual skateboard) to enter the air area of ​​the virtual scene in a sprint state, if no further movement commands are received from player 1 for the virtual skateboard, the virtual skateboard can be controlled to enter a gliding standby state. Simultaneously, to enhance the viewing experience, the virtual skateboard can also transform from a gliding form (i.e., the first form) to a seatable form (i.e., the second form) in this state. Furthermore, the flight speed of the virtual skateboard in the seatable form (i.e., the first flight speed) is lower than its flight speed in the gliding form (i.e., the second flight speed). In other words, after controlling the virtual skateboard to transform from the gliding form to the seatable form, game character A can automatically sit on the transformed virtual skateboard, and the flight speed of the transformed virtual skateboard is lower than its flight speed before transformation, thus providing the player with a better perspective to slowly appreciate the game character and the scenery in the game.

[0089] In step 1022, if the first virtual object is in the air area of ​​the virtual scene and a movement trigger operation for the virtual vehicle is received, the virtual vehicle is controlled to switch from the second form back to the first form and fly in the air area at the second flight speed.

[0090] Here, the second flight speed can be greater than the first flight speed.

[0091] For example, continuing from the above example, taking the first virtual object as the game character A controlled by player 1 and the virtual vehicle as the virtual skateboard, if a movement command is subsequently received from player 1 for the virtual skateboard, the virtual skateboard can be controlled to enter the gliding movement state. At this time, the virtual skateboard can be controlled to return from the sitting state (i.e., the second state) to the gliding state (i.e., the first state) and continue to move at the second flight speed. In this way, it is ensured that the player can freely switch between the movement and standby states while gliding, which improves the flexibility and experience of aerial exploration.

[0092] In some embodiments, when the first region is a water surface region, step 102 above can also be implemented in the following way: in response to the first virtual object being in the water surface region of the virtual scene, the virtual vehicle is controlled to slide in the water surface region.

[0093] For example, taking the first virtual object as the game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, when player 1 controls the virtual skateboard carrying game character A (for example, game character A can be standing on the virtual skateboard) to enter the water area of ​​the virtual scene from the ground area, the player can control the virtual skateboard to glide in the water area (that is, player 1 can control game character A to surf in the water area by using the virtual skateboard). In this way, the player does not need to frequently switch vehicles, realizing automatic and seamless switching between different scenes and avoiding the feeling of interruption in movement or operation.

[0094] In other embodiments, following the examples above, the following processing may also be performed: in response to an acceleration trigger operation for the virtual vehicle, controlling the virtual vehicle to accelerate its gliding motion in the water surface area.

[0095] For example, continuing with the example of the first virtual object being the game character A controlled by player 1 and the virtual vehicle being the virtual skateboard, when player 1 controls game character A to surf on the water surface using the virtual skateboard, they can also control the virtual skateboard to enter a sprint state by pressing the "Shift" key on the keyboard (i.e., the acceleration trigger operation), that is, control the virtual skateboard to accelerate on the water surface. For example, when receiving the click operation of player 1 on the "Shift" key on the keyboard, after consuming a set amount of stamina points of game character A (e.g., 100 stamina points), the virtual skateboard is controlled to accelerate on the water surface. In other words, the technical solution provided by this application embodiment allows players to increase the movement speed of the virtual skateboard by consuming stamina points, thereby saving players' time exploring the water surface and further improving the player's gaming experience.

[0096] In some embodiments, referring to FIG5, FIG5 is a third flowchart of the vehicle processing method for a virtual scene provided in the embodiments of this application. As shown in FIG5, after performing step 102 shown in FIG3, step 103 shown in FIG5 can also be performed. The steps shown in FIG5 will be described in conjunction with the steps shown in FIG5.

[0097] In step 103, in response to the first virtual object entering the second area of ​​the virtual scene from the first area, and the second area being of a different type from the first area, the virtual vehicle is controlled to switch from the first movement mode to the second movement mode adapted to the second area.

[0098] In some embodiments, when controlling a virtual vehicle to move in a first movement mode adapted to a first area, the following processing can also be performed: playing a first sound effect adapted to the first movement mode; after controlling the virtual vehicle to switch from the first movement mode to a second movement mode adapted to a second area, the following processing can also be performed: playing a second sound effect adapted to the second movement mode. For example, when the virtual vehicle is gliding on the ground, a particle sound effect of wheel axles rubbing against the ground can be played; when the virtual vehicle enters the air area from the ground area, a low hum sound effect of the thrusters can be played. In this way, players can intuitively feel the matching degree between the current movement mode and the scene through hearing, avoiding the incongruity of flying in the air but having ground friction sounds, and greatly enhancing the immersion of the virtual scene.

[0099] For example, taking the first virtual object as the game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, when player 1 controls the virtual skateboard carrying game character A to move from the ground area (i.e., the first area) of the virtual scene to the air area (i.e., the second area) of the virtual scene, the virtual skateboard can be controlled to switch from gliding to flying. In other words, player 1 can control game character A to glide in the ground area of ​​the virtual scene or fly in the air area of ​​the virtual scene through the virtual skateboard. In this way, the player does not need to frequently switch vehicles, realizing automatic and seamless switching between different scenes and avoiding the feeling of interruption in movement or operation. Furthermore, the resources for the same virtual vehicle (such as a virtual skateboard) only need to be loaded once at game startup. Subsequent movement in different scenes eliminates the need for frequent unloading and loading of new vehicle models, textures, and other resources, reducing the CPU and memory usage on terminal devices and servers. This helps maintain a stable frame rate and improves overall performance. Simultaneously, since the physical characteristics of the same vehicle are generally fixed, the game's physics engine does not need to frequently adjust parameters to adapt to the physical properties of different vehicles, such as weight, friction, and collision effects. This reduces the complexity of physics simulation and improves the efficiency and accuracy of physics calculations. Additionally, because each virtual vehicle has its unique data structure and attributes, using the same vehicle means the game needs to process relatively less data. This allows for more efficient management of vehicle status, position, and movement data, reducing data processing pressure and preventing slow game performance due to excessive data volume.

[0100] In some embodiments, the player can also control the virtual vehicle to turn, and the following processing can also be performed: in response to a turn trigger operation, the virtual vehicle is controlled to turn, wherein the turning speed of the virtual vehicle can gradually increase as the duration of the turn trigger operation increases.

[0101] For example, taking a virtual skateboard as a virtual vehicle, players can freely control its movement and steering during movement. The steering process can employ a dynamic steering speed mechanism. For instance, the virtual skateboard has an initial steering speed when it begins to turn. As the player continues to input steering input, the steering speed gradually increases to simulate the acceleration felt during real-life turns, thus enhancing the realism and smoothness of the controls. Furthermore, this method can be implemented using simple algorithms, eliminating the need for complex physics engine calculations. For example, a coefficient related to the duration of button presses can be set to adjust the vehicle's steering speed without requiring real-time calculations of complex physical parameters, thereby reducing the burden on the physics engine and improving game performance and stability. Additionally, different scenarios and situations in the game require different steering speeds. For instance, in narrow bends, players can achieve precise, small-amplitude turns by briefly pressing the steering key; while in open areas, players can hold down the steering key to quickly adjust the vehicle's direction. This adjustable steering speed mechanism increases the game's strategic depth, allowing players to develop more reasonable strategies based on the actual situation, enhancing the game's fun and replayability.

[0102] In some embodiments, after performing step 102 shown in FIG3, the following processing may also be performed: in response to a deceleration trigger operation (e.g., the player stops inputting a movement command or the player inputs a stop movement command), the virtual vehicle is controlled to gradually reduce its movement speed according to a set deceleration; in response to the virtual vehicle's movement speed being less than a first speed threshold, the virtual vehicle is controlled to stop moving.

[0103] For example, taking a virtual skateboard as a virtual vehicle, its suspended nature allows for the simulation of physical inertia to enhance realism and the user experience. For instance, when the player stops inputting movement commands (e.g., the player's finger leaves the "W" key on the keyboard), the virtual skateboard doesn't stop immediately. Instead, it gradually reduces its speed according to a pre-set deceleration rate. The magnitude of this deceleration can be dynamically adjusted based on the current speed of the virtual skateboard to achieve a smooth deceleration effect. When the virtual skateboard's speed decreases to a certain threshold (e.g., 0.5 m / s), it can be determined that the virtual skateboard has stopped moving.

[0104] In other embodiments, following the examples above, the control of the virtual vehicle to gradually reduce its speed according to a set deceleration can be achieved in the following ways: in response to the virtual vehicle's speed being greater than a second speed threshold (i.e., high speed), the virtual vehicle is controlled to gradually reduce its speed according to a set first deceleration; in response to the virtual vehicle's speed being less than the second speed threshold but greater than a third speed threshold (i.e., medium speed), the virtual vehicle is controlled to gradually reduce its speed according to a set second deceleration, wherein the third speed threshold is less than the second speed threshold; in response to the virtual vehicle's speed being less than the third speed threshold (i.e., low speed), the virtual vehicle is controlled to gradually reduce its speed according to a set third deceleration.

[0105] For example, continuing with the virtual skateboard as a virtual vehicle, to enhance the visual feedback, different stopping actions can be played based on the skateboard's deceleration process and final speed when it stops. For instance, when the virtual skateboard stops at high speed, a longer or more pronounced stopping action can be played to simulate a strong inertial effect (e.g., the virtual skateboard stops after gliding a certain distance); when the virtual skateboard stops at medium speed, a smoother stopping action can be played, such as the virtual skateboard gradually decelerating and then stopping naturally; when the virtual skateboard stops at low speed, the stopping action is smaller, such as the virtual skateboard rapidly decelerating and stopping easily, and the action can also rely on a combination of movements to create a natural stopping motion. In this way, by introducing the inertia mechanism, the movement and stopping of the skateboard will be more natural, and players can feel the realistic physical feedback of the virtual skateboard at different speeds. At the same time, different stopping actions further enhance the visual expressiveness, making the whole process more immersive and refined.

[0106] In some embodiments, a second virtual object may also be displayed in the virtual scene. The second virtual object and the first virtual object may be adversaries, for example, belonging to two opposing virtual factions in the virtual scene (i.e., the second virtual object is the enemy of the first virtual object). In this case, the following processing can be performed: in response to a shooting trigger operation, a shooting prop (e.g., a virtual wingman that moves with the first virtual object) is displayed around the first virtual object, and the shooting prop is controlled to fire at the second virtual object. Thus, using an additional shooting prop ensures that players can perform accurate and smooth combat operations even during high-speed movement, enhancing the player's gaming experience. Furthermore, compared to having players directly control shooting props for complex aiming and shooting operations, this automatic shooting method simplifies the physics engine's calculations. The physics engine only needs to handle the basic trajectory of the shooting prop and collision detection with enemies, without needing to calculate various complex physical parameters when the player manually operates the shooting prop in real time, reducing computational complexity and improving game performance and stability.

[0107] In other embodiments, following the examples above, before controlling the shooting prop to fire at the second virtual object, the following processing can also be performed: controlling the shooting prop to scan a first reference direction (e.g., horizontal direction) of the virtual scene; in response to the second virtual object moving in the first reference direction, controlling the scope of the shooting prop to move synchronously in the first reference direction to lock onto the second virtual object; in response to the first virtual object moving in a second reference direction (e.g., vertical direction) of the virtual scene, controlling the shooting prop to move synchronously in the second reference direction. This ensures that players do not need to perform tedious aiming operations, and allows the shooting prop to better adapt to terrain changes, thereby ensuring smooth shooting operations.

[0108] For example, taking the first virtual object as a game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, when an enemy (i.e., the second virtual object, such as a game character B controlled by a bot account) is detected in the virtual scene, in skateboard mode (i.e., the virtual skateboard carrying game character A), player 1 can fire in mid-air by clicking the left mouse button. For instance, when player 1 clicks the left mouse button (i.e., triggers a shot), a virtual wingman (i.e., a shooting tool) that moves with game character A can be displayed in the virtual scene. The virtual wingman will automatically scan and lock onto enemies horizontally, ensuring that player 1 does not need cumbersome aiming operations. Furthermore, the virtual wingman's target acquisition range can be dynamically adjusted according to game character A's perspective and direction of movement to cover a reasonable attack area. Additionally, the virtual wingman can automatically adjust its altitude according to game character A's current altitude in the virtual scene, ensuring that the virtual wingman maintains an appropriate relative vertical position with game character A, thus better adapting to terrain changes and ensuring smooth shooting operations. Thus, the auto-aiming feature reduces the computational demands of manual player input. The game engine doesn't need to handle complex aiming angle and firing trajectory calculations in real-time, reducing the burden on terminal devices and server CPUs and GPUs, which helps improve game frame rates and operational stability. Furthermore, in multiplayer online games, the automatic operation of virtual wingmen is relatively simple. The server only needs to process less player action data and wingman status changes, facilitating network synchronization, reducing network latency and data transmission volume, and improving game network stability.

[0109] In some embodiments, a shooting control (e.g., an attack button) may also be displayed in the virtual scene. The above-mentioned response to a shooting trigger operation can be achieved by displaying shooting props around the first virtual object and controlling the shooting props to fire at the second virtual object in the following ways: In response to a click operation on the shooting control, a shooting prop is displayed around the first virtual object, and the shooting props are controlled to fire a set number (e.g., one or more) of virtual projectiles at the second virtual object; In response to a press operation on the shooting control, a shooting prop is displayed around the first virtual object, and before the press operation is released, the shooting props are controlled to continuously fire virtual projectiles at the second virtual object; wherein, when the second virtual object moves within the virtual scene, the virtual projectiles are controlled to move synchronously to lock onto the second virtual object.

[0110] For example, taking the first virtual object as game character A controlled by player 1 and the second virtual object as game character B controlled by a bot account (i.e., a non-player character in the virtual scene), game character A and game character B can be in an adversarial relationship. When player 1 clicks the attack button, the virtual wingman can fire a single virtual bullet. The virtual bullet can automatically lock onto game character B, ensuring accurate hits even while moving. When player 1 holds down the attack button, the virtual wingman can automatically fire continuously. Simultaneously, the virtual wingman can continuously lock onto game character B, and the virtual bullets fired by the virtual wingman also have a lock-on function, ensuring continuous accuracy. In other words, whether it's a click or a hold, the fired virtual bullets will automatically follow the currently locked target; the trajectory of the virtual bullets can be dynamically adjusted according to the target's movement to improve the hit rate.

[0111] In some embodiments, players can also control a first virtual object carried by a virtual vehicle to attack enemies (e.g., a second virtual object in a virtual scene). The following processing can also be performed: If the first virtual object is on the ground, in response to an attack triggering operation (e.g., clicking the "E" key on a keyboard or clicking an attack button displayed on the screen), if there is no second virtual object in the virtual scene, or if the second virtual object in the virtual scene is outside the attack range of the first virtual object, then the first virtual object is controlled to perform an attack action in place; if the first virtual object is in the air, in response to an attack triggering operation, if there is no second virtual object in the virtual scene, then the first virtual object is controlled to fall towards the ground of the virtual scene and perform an attack action during the fall.

[0112] For example, taking the first virtual object as game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, in skateboard mode (i.e., the virtual skateboard carrying game character A), player 1 can trigger game character A to perform an attack action (such as a kick) by pressing the "E" key on the keyboard (i.e., an attack trigger operation). For instance, upon receiving player 1's press of the "E" key, if game character A is currently on the ground in the virtual scene and there are no targets nearby (such as game character B, which is hostile to game character A), or if the target is outside game character A's attack range, then game character A can be controlled to perform an attack action in place. If game character A is currently in the air in the virtual scene and there are no suitable targets nearby, then game character A can be triggered to perform a falling attack. For example, game character A can be controlled to fall directly to the ground in the virtual scene. This type of attack can be used to deal with enemies on the ground or to quickly land from the air.

[0113] In other embodiments, following the examples above, when an enemy (e.g., a second virtual object in a virtual scene) is within the attack range of the first virtual object, the following processing can also be performed: if the first virtual object is in a ground area, in response to an attack triggering operation, if the second virtual object is within the attack range of the first virtual object, the first virtual object is controlled to move to the location of the second virtual object at a set movement speed (e.g., the first virtual object is controlled to dash to the location of the second virtual object), and an attack action is performed on the second virtual object; if the first virtual object is in an air area, in response to an attack triggering operation, if the second virtual object is within the attack range of the first virtual object, the first virtual object is controlled to dive from the air to the location of the second virtual object, and an aerial strike action is performed on the second virtual object.

[0114] For example, continuing with the example of the first virtual object being game character A controlled by player 1 and the second virtual object being game character B controlled by a bot account (i.e., a non-player character in the virtual scene), game character A and game character B can be adversaries. Assuming game character A is on the ground in the virtual scene and receives a click on the "E" key by player 1 (i.e., controlling game character A to launch a flying kick on the ground), and the distance between game character A and game character B is less than a distance threshold (i.e., game character B is within the attack range of game character A), then... Players can control character A to dash towards character B at high speed and execute powerful melee attacks upon contact, such as kicking or knocking B back. If character A is in the air and receives a press of the "E" key (initiating a flying kick), character A can swoop down to character B's location and perform a more dynamic aerial attack. In other words, the visual impact of a flying kick is more intense than a ground-based one. This allows players to detach from their skateboard and charge towards a target with a single button press, quickly engaging in melee combat, achieving a seamless transition between combat and movement and avoiding any sense of interruption. Furthermore, ground and aerial flying kicks can be implemented using pre-designed animation sequences and physics models, reducing the complexity of real-time calculations and improving game performance. At the same time, the judgment and execution of the flying kick can be combined with the game's collision detection system to ensure the accuracy and smoothness of the attack without having too much impact on the overall performance of the game.

[0115] In some embodiments, the player can also control a virtual vehicle to jump with the first virtual object. In this case, the following processes can also be performed: in response to a sprint trigger operation on the virtual vehicle, control the virtual vehicle to enter a sprint state (i.e., a high-speed movement state); in response to a jump trigger operation on the virtual vehicle in the sprint state (e.g., a click operation on the jump button displayed on the screen, or a click operation on the space bar on the keyboard, etc.), control the virtual vehicle to jump with the first virtual object.

[0116] For example, taking the game character A controlled by player 1 as the first virtual object and the virtual vehicle as a virtual skateboard, while the virtual skateboard is moving with game character A, the player can control the virtual skateboard to enter sprint mode by pressing the "Shift" key on the keyboard (i.e., the sprint trigger operation). For instance, when receiving a click on the "Shift" key from player 1, the player can control the virtual skateboard to enter sprint mode, that is, control the virtual skateboard to accelerate gliding or flying. If, while the virtual skateboard is in sprint mode, the player receives a click on the space bar on the keyboard (i.e., the jump trigger operation), the player can control the virtual skateboard to jump together with game character A. Compared to jumping in normal mode, the virtual skateboard jumps higher in sprint mode, thus overcoming some low obstacles in the virtual scene (i.e., the height of the obstacles is less than the height of the virtual skateboard jump in sprint mode), further enhancing the player's gaming experience.

[0117] In other embodiments, when the virtual vehicle is moving while carrying the first virtual object, the player can also control the virtual vehicle to accelerate. In this case, the following processes can also be performed: in response to an acceleration trigger operation on the virtual vehicle, control the virtual vehicle to accelerate; in response to the acceleration duration of the virtual vehicle reaching (i.e., greater than or equal to) a duration threshold (e.g., 10 seconds), control the virtual vehicle to gradually decelerate to the movement speed before acceleration.

[0118] For example, taking a virtual skateboard as a virtual vehicle, while the virtual skateboard carries the first virtual object (e.g., game character A controlled by player 1), player 1 can press the "Ctrl" key on the keyboard (i.e., the acceleration trigger operation) to control the virtual vehicle to enter a boost state, that is, to control the virtual vehicle to accelerate gliding or flying. In boost state, the virtual skateboard's movement speed increases, gravity decreases, and turning speed changes. After a period of time (e.g., 30 seconds), the virtual skateboard can return from boost state to normal state. In addition, compared to sprint state, boost state consumes less stamina, and game character A's stamina does not recover in boost state, and jumping is not possible, but the virtual skateboard can be removed. If game character A's stamina is insufficient, the boost function can be disabled until game character A's stamina recovers to a sufficient level (i.e., greater than or equal to the stamina threshold). Thus, by introducing a parkour mode into the skateboard, the movement speed of the virtual skateboard can be increased, thereby saving players the time spent exploring the virtual scene.

[0119] In some embodiments, the virtual vehicle provided in this application may also have an obstacle avoidance function, and may further perform the following processing: in response to the obstacle avoidance triggering operation, obstacle detection is performed on the virtual scene; when a virtual obstacle is detected in front of the virtual vehicle, and the height of the virtual obstacle is less than a height threshold (i.e., a virtual obstacle with a low height) and the width of the virtual obstacle is less than a width threshold, in response to the distance between the virtual vehicle and the virtual obstacle being less than a distance threshold (e.g., 2 meters), the virtual vehicle is controlled to perform a vaulting action to cross the virtual obstacle, so as to avoid the feeling of interruption of movement.

[0120] For example, taking the first virtual object as a game character A controlled by player 1 and the virtual vehicle as a virtual skateboard, the obstacle avoidance function can be triggered when the virtual skateboard is in a sprinting state and a direction is input. For instance, when the angle between the direction input by player 1 and the movement direction of the virtual skateboard is detected to be less than a certain angle, obstacle detection in the horizontal direction can be triggered. The detection distance can be adjusted according to the current movement state of the virtual skateboard; for example, the greater the current movement speed of the virtual skateboard, the greater the detection distance, and the smaller the current movement speed, the smaller the detection distance. In addition, during obstacle avoidance, the height of the virtual obstacle can be detected upwards first, and then the distance can be detected forwards to determine whether to trigger the virtual skateboard to perform a vaulting action. If there are still virtual obstacles after vaulting, the passability can be further detected; if there are still virtual obstacles, the vaulting is canceled.

[0121] It should be noted that the obstacle avoidance process can be divided into two stages: the first stage uses motion warping (a technique used in character animation, typically to adjust the displacement and rotation of animations when a character performs certain actions, making them more accurately match the dynamic environment in the game) to ensure that the virtual skateboard can correctly traverse virtual obstacles; the second stage overwrites the virtual skateboard's falling parameters (such as gravity and initial velocity during gliding or sprinting) to allow the virtual skateboard to smoothly transition to a normal state. After successful obstacle avoidance, the virtual skateboard can recover to its normal movement state based on its current state (e.g., sprinting state) and play the corresponding animation. Furthermore, this embodiment can optimize the triggering conditions of the obstacle avoidance function (e.g., the angle limit between the input direction and the movement direction) to prevent unnecessary obstacle avoidance triggers, thereby saving terminal device resources and further improving the player's gaming experience.

[0122] In other embodiments, the virtual vehicle provided in this application may also have an obstacle climbing function, and may further perform the following processing: when there is a virtual obstacle in front of the virtual vehicle with a height greater than a height threshold (i.e., a tall virtual obstacle), in response to the distance between the virtual vehicle and the virtual obstacle being less than a distance threshold, the movement direction of the virtual vehicle is automatically adjusted to a direction corresponding to the height of the virtual obstacle (e.g., a vertically upward direction). That is, when the virtual vehicle approaches a tall virtual obstacle, the movement direction of the virtual vehicle can be automatically adjusted to a vertically upward direction to climb the tall virtual obstacle.

[0123] For example, taking a virtual skateboard as a virtual vehicle, in sprint mode, when the virtual skateboard encounters a tall virtual obstacle, its movement direction can be automatically rotated to be perpendicular to the obstacle and enter a special climbing mode. In this mode, the virtual skateboard's movement always has an upward component; adjustments to the left and right directions only slightly change its left and right position without deviating from the upward climbing trend. This reduces the complexity of player controls, eliminating the need for precise directional control on different devices, while ensuring the game character can successfully traverse virtual obstacles. Furthermore, automatically rotating to be perpendicular to the obstacle and entering climbing mode simplifies the physics engine's processing logic. The physics engine only needs to calculate the skateboard's trajectory according to preset climbing mode rules, without needing to handle complex collision angles and bounce effects in real time, reducing the complexity of physics simulation and improving computational efficiency. Additionally, in multiplayer online games, this fixed-mode skateboard movement is relatively simple; the server only needs to handle fewer motion parameters and state changes, facilitating network synchronization, reducing network latency and data transmission volume, and improving the game's network stability.

[0124] In some embodiments, following the above examples, the following processing may also be performed: in response to the vehicle removal operation, the virtual vehicle is de-displayed in the virtual scene, and the first virtual object is controlled to continue climbing the virtual obstacle from the position where the virtual vehicle disappeared.

[0125] For example, continuing with the example of the first virtual object being the game character A controlled by player 1 and the virtual vehicle being the virtual skateboard, player 1 can remove the skateboard in a special way while in the skateboard climbing state (e.g., by pressing the space bar on the keyboard). At this time, game character A will directly switch to the basic climbing state, remaining at the position where the virtual skateboard disappeared on the virtual obstacle. Player 1 can then make more precise adjustments to the position of game character A to ensure a more accurate climbing experience. In other words, this embodiment provides operational flexibility while ensuring a smooth transition, facilitating rapid movement for players in complex terrain and further enhancing the player's gaming experience. Furthermore, after removing the skateboard, the game's physics engine no longer needs to handle the skateboard's physical simulation. This allows the physics engine to focus more on the basic climbing physics calculations for game character A, simplifying the calculation process and improving the accuracy and real-time performance of the physical simulation, allowing for more timely and reasonable feedback on the player's fine-tuning operations. Additionally, the presence of the skateboard may increase the complexity of collision detection, as it requires considering the collision relationships between the skateboard and obstacles, as well as between the character and the skateboard. After removing the skateboard, collision detection is mainly focused on the game character A and the virtual obstacles. This reduces the number of objects and the scope of collision detection, lowers the computational load of collision detection, and improves the efficiency and accuracy of collision detection. This helps players to more accurately control the position of the game character A on the obstacles.

[0126] The virtual vehicle processing method provided in this application provides multiple movement modes for exploring virtual scenes (such as ground gliding, sprinting, automatic obstacle avoidance, climbing, gliding, surfing, etc.), comprehensively covering land, sea, and air in the virtual scene, greatly improving movement efficiency and operational flexibility. Furthermore, the virtual vehicles provided in this application also possess spatial movement skills such as jetting, jumping, and double jumping, and integrate combat capabilities such as shooting and attacking, allowing players to both remotely engage enemies and quickly engage in close combat during exploration, balancing high mobility and combat performance.

[0127] The following example, using a virtual skateboard (hereinafter referred to as skateboard) as a virtual vehicle, illustrates an exemplary application of the embodiments of this application in a real-world application scenario.

[0128] This application provides a vehicle processing method for virtual scenes, offering multiple movement modes for open-world exploration (such as ground gliding, sprinting, automatic obstacle avoidance, climbing, gliding, and surfing), comprehensively covering land, sea, and air, greatly improving movement efficiency and operational flexibility. Furthermore, the skateboard operating system provided in this application also possesses spatial movement skills such as jetting, jumping, and double jumping, and integrates combat capabilities such as skateboard shooting and flying kicks, allowing players to both remotely engage enemies and quickly engage in close combat during exploration, thus balancing high mobility and combat performance.

[0129] Specifically, this application embodiment provides an active movement mode, a double jump, and a jet propulsion for both vertical and horizontal directions. Both active movement modes allow players to interrupt and turn during activation, ensuring a smooth and responsive experience. Furthermore, this application embodiment introduces a parkour mode into the skateboard. Activating parkour mode increases the skateboard's speed and automatically initiates climbing when encountering obstacles, gliding when suspended in the air, and surfing upon landing on water, achieving seamless switching between different scenarios and avoiding any sense of interruption in movement or operation. Additionally, the skateboard provided in this application embodiment possesses unique combat capabilities, enabling ranged attacks from the skateboard. When approaching enemies (such as monsters in a game), players can detach from the skateboard with a single click and charge towards the monster, quickly closing the distance and achieving seamless switching between combat and special movement modes.

[0130] The following is a detailed description of the vehicle processing method for virtual scenes provided in the embodiments of this application.

[0131] In some embodiments, the skateboard function can have different forms and mechanisms. For example, players can press the "Summon Skateboard" button (e.g., the "T" key on the keyboard or a virtual summon button on the screen) when the game character is in a standby, moving, or falling state to enter skateboard mode (i.e., the skateboard is displayed under the game character's feet). In skateboard mode, players can press the "Dismount Skateboard" button (e.g., the "T" key on the keyboard) to dismount the game character from the skateboard.

[0132] For example, referring to Figure 6A, which is a schematic diagram of a first application scenario of the vehicle processing method in a virtual scene provided in this application embodiment, as shown in Figure 6A, a game character 601 controlled by the current player is displayed in the virtual scene. For example, the game character 601 in a standby state can be displayed in the virtual scene from a third-person perspective. When the player clicks the "T" key on the keyboard, a skateboard 602 can be displayed under the feet of the game character 601, that is, the game character 601 can be controlled to enter the skateboard state. In the skateboard state, if the player clicks the "T" key on the keyboard again, the skateboard 602 can be dedisplayed under the feet of the game character 601, that is, the game character 601 can be controlled to leave the skateboard state.

[0133] It's worth noting that during the summoning and removal of the skateboard, different animations and operational logic can be executed based on the game character's current movement state. For example, when the game character summons or removes the skateboard, the original movement state can be preserved. If the game character is moving, an animation of "summoning the skateboard while moving" can be played; if the game character is stationary, an animation of "summoning the skateboard while stationary" can be played. Furthermore, during movement, players can freely control the game character's movement and turning. The turning process can employ a dynamic turning speed mechanism. Specifically, the game character has an initial turning speed when starting to turn, and as the player continues to input turning input, the game character's turning speed will gradually increase to simulate the acceleration felt during real-world turning, thereby enhancing the realism and smoothness of the operation. In this way, the summoning and removal of the skateboard can be naturally integrated into the character's movement state, providing players with a more realistic and smooth turning operation experience.

[0134] In some embodiments, players can control the skateboard's movement using the "WASD" keys on the keyboard. For example, a click on the "W" key moves the skateboard forward, a click on the "S" key moves it backward, a click on the "A" key moves it left, and a click on the "D" key moves it right. Additionally, while skateboarding, players can also use the spacebar to jump.

[0135] For example, referring to Figure 6B, which is a schematic diagram of a second application scenario of the vehicle processing method for a virtual scene provided in this application embodiment, when the game character 601 is in skateboard mode, if a player clicks the space bar on the keyboard, the skateboard 602 can be controlled to make the game character 601 jump together. Furthermore, if a player clicks the space bar again during the jump of the skateboard 602, the skateboard 602 can be controlled to perform a double jump.

[0136] It's worth noting that the skateboard's suspended nature allows for the simulation of real-world inertia, enhancing realism and the overall driving experience. Specifically, the skateboard doesn't stop abruptly upon ceasing movement; instead, it gradually decelerates based on its current speed until it comes to a complete stop. For example, when the player stops inputting movement commands, the skateboard will gradually reduce its speed according to a pre-set deceleration rate. This rate can be dynamically adjusted based on the skateboard's current speed to achieve a smooth deceleration effect. Furthermore, the skateboard can be considered to have stopped moving when its speed reaches a certain threshold.

[0137] To enhance visual feedback, different stopping animations can be played based on the skateboard's deceleration process and final speed. For example, for a high-speed stop, if the skateboard stops at high speed, a longer or more pronounced stopping animation can be played to simulate a strong inertial effect (e.g., the skateboard stops after traveling a certain distance). For a medium-speed stop, if the skateboard stops at a medium speed, a smoother stopping animation can be played, showing the skateboard gradually decelerating and coming to a natural stop. For a low-speed stop, if the skateboard stops at a low speed, the animation is smaller, showing the skateboard decelerating quickly and stopping easily, and the stopping animation can also be combined with other movements to create a natural stop. In this way, by introducing an inertial mechanism, the skateboard's movement and stopping process becomes more natural, allowing players to feel the realistic physical feedback of the skateboard at different speeds. Furthermore, the different stopping animations further enhance the visual appeal, making the entire system more immersive and refined.

[0138] In some embodiments, referring to FIG6C, FIG6C is a schematic diagram of a third application scenario of the vehicle processing method in a virtual scene provided in the embodiments of this application. As shown in FIG6C, when the game character 601 is in skateboard mode and encounters an enemy (e.g., game character 603) in the virtual scene, the player can shoot the enemy in the air by clicking the left mouse button. For example, when the player clicks the left mouse button, a virtual wingman 604 following the game character 601 can be displayed in the virtual scene, and the virtual wingman 604 can be controlled to shoot the game character 603 (e.g., a monster in the virtual scene).

[0139] In other words, the skateboard shooting provided in this application embodiment can employ a wingman assistance mechanism, providing automatic target acquisition and pursuit attacks to ensure that players can still perform combat operations accurately and smoothly even while moving at high speeds. For example, referring to Figure 6D, which is a schematic diagram of the fourth application scenario of the vehicle processing method for virtual scenes provided in this application embodiment, as shown in Figure 6D, the virtual wingman 604 automatically scans and locks onto enemies (such as the game character 603) in the horizontal direction, ensuring that players do not need to perform cumbersome aiming operations. Furthermore, the target acquisition range of the virtual wingman 604 can be dynamically adjusted according to the viewpoint and direction of movement of the game character 601 to cover a reasonable attack range.

[0140] In other embodiments, see Figure 7, which is a schematic diagram of the principle of the vehicle processing method in the virtual scene provided in the embodiments of this application. As shown in Figure 7, the height of the virtual wingman 702 can be automatically adjusted according to the height of the game character 701 in the virtual scene. That is, the wingman will automatically adjust its own height according to the current height of the game character, so as to ensure that it maintains an appropriate relative vertical position with the game character, thereby better adapting to terrain changes and ensuring smooth shooting operation.

[0141] The attack patterns of wingmen will be explained below.

[0142] In some embodiments, the wingman's attack mode can be divided into tap attack and hold attack. For example, when the player taps the attack button, the wingman can fire a single bullet, and the bullet can automatically track the locked target, thus ensuring accurate hits on enemies while moving. When the player holds down the attack button, the wingman can automatically fire continuously, and the wingman can continuously lock onto enemies. The bullets also have an automatic tracking function to ensure continuous accuracy. In other words, whether tapping or holding down the attack button, the bullets will automatically track the currently locked target, meaning the bullet's trajectory can be dynamically adjusted based on the enemy's movement to improve hit rate.

[0143] In other words, the wingman mechanism provided in this application significantly simplifies the player's aiming operation, allowing the player to focus on riding and moving the skateboard while maintaining efficient shooting capabilities, even at high speeds. Furthermore, this method is suitable for multi-platform operation; whether on mobile, console, or PC, players can easily use simple input methods for accurate shooting without complex aiming operations, thus enhancing the player's gaming experience.

[0144] In some embodiments, referring to FIG6E, FIG6E is a schematic diagram of the fifth application scenario of the vehicle processing method in a virtual scene provided in this application embodiment. As shown in FIG6E, when the game character 601 is in skateboard mode, if an enemy (e.g., game character 605) is encountered in the virtual scene, and the distance between game character 601 and game character 605 is less than a distance threshold, the player can control game character 601 to perform a flying kick attack on game character 605 by pressing the "E" key on the keyboard. For example, upon receiving the player's press operation on the "E" key on the keyboard, the player can control game character 601 to dismount from the skateboard and rush towards game character 605 at high speed, performing a powerful melee attack upon contact, such as directly kicking game character 605 or knocking game character 605 back. In this way, the game character can quickly approach the target and smoothly connect the battle.

[0145] It's important to note that different attack methods can be triggered depending on the presence of a target and the distance between the target and the game character. Specifically: When there is no target nearby, or the target is too far away for a flying kick, the game character will perform the attack in place. If the game character is currently in the air, a falling attack can be triggered, meaning the game character can perform a kick while on the ground. When the game character is in the air and there is no suitable target, the game character will perform a falling attack directly to the ground. This attack method can be used to deal with enemies on the ground or to quickly land from the air. If a target is detected and the distance between the target and the game character is less than a distance threshold, the game character can automatically lock onto the target and perform a flying kick, meaning the game character will quickly fly towards the target. Specifically, the game character can automatically adjust the angle and path towards the target to ensure the flying kick accurately hits the target. Furthermore, the speed and trajectory of the flying kick can be dynamically adjusted based on the distance between the target and the game character to ensure the smoothness of the flying kick action.

[0146] In addition, it should be noted that if the game character launches a flying kick on the ground, the game character will rush towards the target at high speed and perform a powerful melee attack upon contact, such as directly kicking the target or knocking the target back; if the game character launches a flying kick in the air, the game character can swoop down from the air to the target and perform a more dynamic aerial attack, in which case the visual performance of the flying kick will be more intense.

[0147] In some embodiments, referring to FIG6F, FIG6F is a schematic diagram of a sixth application scenario of the vehicle processing method in a virtual scene provided in this application embodiment. As shown in FIG6F, a game character 601 in a skateboard state is displayed in the virtual scene. When the game character 601 is in a moving state or in the air, the player can control the skateboard 602 to enter a jet state by pressing the "Ctrl" key on the keyboard. For example, when the player's "Ctrl" key is pressed, the skateboard 602 can be controlled to enter a jet state. In the jet state, the movement speed of the skateboard 602 will be greatly increased.

[0148] It's worth noting that the skateboard boost function can be triggered not only by pressing the "Ctrl" key on the keyboard but also by using a touch button. In boost mode, the character's movement speed increases, gravity decreases, and turning speed also changes, returning to normal after a short period. The boost function can be activated while gliding or sprinting; gliding boosts consume less stamina, while sprint boosts consume more. Unlike normal movement, the character's stamina does not regenerate during boost mode, and jumping is impossible, but the skateboard can be removed. If the character's stamina is insufficient, the boost function will be disabled until it recovers to a sufficient level.

[0149] In other words, the boost state can be divided into gliding boost and dash boost based on the game character's current action, and the acceleration, turning speed, and gravity control of each can be set with different parameters. Furthermore, when a boost is initiated, the game character can trigger specific animations and sound effects to simulate the dynamic performance of high-speed movement. After the boost ends, the skateboard will gradually decelerate and return to the default gliding or dash state, while actions such as jumping can interrupt the recovery process. Specific changes in turning and speed can be controlled by configuring different parameters.

[0150] In some embodiments, referring to Figure 6G, which is a schematic diagram of the seventh application scenario of the vehicle processing method in a virtual scene provided in this application embodiment, as shown in Figure 6G, a game character 601 in a skateboard state is displayed in the virtual scene. The player can control the game character 601 to enter a sprint state by pressing the "Shift" key on the keyboard. After entering the sprint state, the skateboard 602 will accelerate and gain the ability to go at high speed and automatically switch movement modes. At this time, if it encounters a low obstacle, it will enter the skateboard obstacle avoidance mode; if it encounters a high obstacle, it will enter the climbing mode; when it is suspended in the air, it will trigger gliding; and when it enters the water surface, it will trigger water surfing, which will be described in detail below. In addition, if the player subsequently clicks the space bar on the keyboard (for example, the player presses the space bar repeatedly), the skateboard 602 can be controlled to jump in the sprint state.

[0151] In other embodiments, referring to Figure 6H, which is a schematic diagram of the eighth application scenario of the vehicle processing method for virtual scenes provided in this application embodiment, as shown in Figure 6H, when the game character 601 is in a sprinting state, if the angle between the direction input by the player and the movement direction of the game character 601 is less than a certain angle (e.g., 10 degrees), the skateboard obstacle avoidance function can be triggered. That is, the skateboard obstacle avoidance function is triggered when the game character is in a sprinting state and there is an input direction. The system can detect obstacles in the horizontal direction, wherein the detection distance can be adjusted according to the current movement state of the game character 601. When avoiding obstacles, the height of the obstacle can be detected upward first, and then the distance can be detected forward to determine whether to trigger the skateboard 602 to perform a vaulting action. If there is an obstacle blocking the way after vaulting, the passability can be further detected, and if there is an obstacle, the vaulting is canceled.

[0152] It should be noted that the obstacle avoidance action can be divided into two parts: the first part uses motion wrapping to ensure that the game character can correctly traverse obstacles; the second part overrides the game character's falling parameters (such as gravity and initial velocity during gliding or sprinting), allowing the game character to smoothly transition to a normal state. Motion wrapping is a new animation feature in Unreal Engine, primarily used to dynamically adapt the character to different terrains or scenes by scaling animation clips. Its core principle is to scale and deform the root skeleton motion of the animation within a range, allowing the game character to achieve a natural transition across different terrain heights or movement amplitudes. After successful obstacle avoidance, the game character can resume its corresponding movement state based on its current state (e.g., sprinting) and play the corresponding animation. Furthermore, this embodiment can optimize the triggering conditions for the obstacle avoidance function (e.g., limiting the angle between the input direction and the movement direction) to prevent unnecessary obstacle avoidance triggers.

[0153] In some embodiments, when the game character is in the air, the skateboard gliding function can be divided into two states: gliding movement and gliding standby. For example, as shown in Figure 6I, when the player does not input a movement command, the game character 601 can enter the gliding standby state. To enhance the viewing experience, the skateboard 602 transforms into a sitable form in this state, allowing the game character 601 to automatically sit on the transformed skateboard 602, thus providing the player with a better perspective to appreciate the game character and game scene. Furthermore, if the player subsequently inputs a movement command, the game character can enter the gliding movement state, at which point the skateboard will return to its gliding form and continue moving. This ensures that the player can freely switch between movement and standby states while gliding, enhancing the flexibility and experience of aerial exploration.

[0154] In other embodiments, referring to Figure 6J, which is a schematic diagram of the tenth application scenario of the vehicle processing method for virtual scenes provided in this application embodiment, as shown in Figure 6J, if the game character 601 encounters a high virtual obstacle while sprinting, the game character 601 can be controlled to enter a skateboard climbing state. That is, while sprinting, when the game character 601 encounters a high obstacle, the movement direction of the skateboard 602 will automatically rotate to a direction perpendicular to the wall and enter a special climbing operation mode. In this mode, the movement of the skateboard 602 always has an upward component, and the adjustment of the left and right directions will only slightly change the left and right position of the skateboard 602, without deviating from the upward climbing trend. In this way, the operation complexity of the player can be reduced, so that no fine control of direction is required when operating on different devices, while ensuring that the game character can successfully cross obstacles.

[0155] It's worth noting that while in skateboard climbing mode, players can remove the skateboard using a special method. The game character will then immediately switch to basic climbing mode, remaining at the position where the skateboard disappeared on the obstacle. This allows for more precise adjustments to the character's position, ensuring a more accurate climbing experience. This not only provides greater control flexibility but also ensures a smooth transition, facilitating rapid movement through complex terrain.

[0156] In some embodiments, referring to Figure 6K, which is a schematic diagram of the eleventh application scenario of the vehicle processing method in the virtual scene provided in the embodiments of this application, as shown in Figure 6K, after the game character 601 enters the water surface area 606 of the virtual scene, the player can also control the game character 601 to enter the sprint state by pressing the "Shift" key on the keyboard. That is to say, in the water gliding state, the player is allowed to consume the skateboard power to glide on the water surface. At the same time, the player can also use the "Shift" key on the keyboard to control the game character 601 to enter the sprint state, consume stamina more quickly to glide on the water surface, that is, in the sprint state, the gliding speed of the skateboard 602 in the water surface area 606 will be greatly increased.

[0157] The vehicle processing method for virtual scenes provided in this application embodiment will be further described below with reference to Figure 8.

[0158] For example, see Figure 8, which is a schematic diagram of the skateboard state transition provided in the embodiment of this application. As shown in Figure 8, the skateboard provided in the embodiment of this application has a complex transition relationship and basically follows the following logic: 1. In most non-skateboard states, the skateboard can be summoned at any time without interrupting the movement state of the game character itself; 2. In most skateboard states, the skateboard can be removed without interrupting the movement state of the game character itself; 3. When the character is in skateboard mode on the ground or water, or when entering gliding, sprinting, or water gliding, a button can be pressed to jump, and a second button can be pressed during the jump; 4. When the character is in the air in skateboard mode, only one jump can be performed; 5. The game character can perform a boost in any skateboard state.

[0159] It should be noted that the skateboard's logical state can be controlled through commands and state mechanisms, thereby ensuring precise control over interruption relationships and state transitions under different conditions. The flow of actions can be managed through a state machine, ensuring natural and smooth transitions between different states without affecting the game character's current movement.

[0160] Furthermore, it should be noted that the skateboarding state and the parkour state are two independent states. The skateboarding state is responsible for determining whether the game character is on the ground, in the air, or on water, while the parkour state determines whether the game character consumes stamina and unlocks advanced movement abilities (such as climbing and gliding). This ensures operational flexibility in the skateboarding state, and because the operation is simplified, it can well support the operational needs of different devices (such as mobile devices and consoles). In addition, to handle the complex interruption relationships of the skateboarding, this application embodiment also adopts the instruction and state control relationship table shown in Table 1.

[0161] Table 1. Relationship between Commands and Status Control

[0162] In summary, the vehicle processing method for virtual scenes provided in this application has the following beneficial effects:

[0163] 1) Enhanced Immersion: Through a complex state transition design, players can become more immersed in the game world, and every action of the game character is closely related to the player's finger operations, avoiding the jarring feeling caused by unsmooth state transitions. At the same time, the various abilities and operation linkages in skateboard mode make the player's gaming experience in skateboard mode even more captivating.

[0164] 2) Greater freedom of control: Players can flexibly perform actions such as jumping, double jumping, and boosting in skateboard mode, greatly improving the controllability and maneuverability of the game character. In particular, the operational feedback provided according to different scenarios (such as ground, water, and air) enhances the player's sense of control, making the game experience richer and more in-depth.

[0165] 3) The synergy between double jumps and boosts: The combination of jumps and boosts allows players to perform complex maneuvers in the air, further increasing the game's challenge and depth of operation. Players need to react quickly in different scenarios, such as how to use jumps and boosts effectively to avoid obstacles or quickly reach the target location when gliding from the air to the ground.

[0166] 4) Two-Dimensional State Division: The logical separation of skateboarding and parkour states greatly improves the system's scalability. Developers can easily add new skateboarding features or abilities based on this design without making large-scale adjustments to the overall system's state logic. At the same time, the different state divisions also simplify system maintenance and optimize development and iteration efficiency. During the player experience, this adaptive map-running capability also significantly improves the smoothness of navigating large maps.

[0167] 5) Modular design facilitates expansion: The technical solution provided in this application uses a complex instruction and state control mechanism to handle the relationships between different skateboard states, making the system highly scalable. If new skateboard capabilities (such as gliding sprints, special skills, etc.) need to be introduced in the future, they can be expanded based on the existing state control logic without breaking existing functions.

[0168] 6) Multi-scene adaptability: The skateboard state transition technology provided in this application embodiment is not only applicable to the ground, but also adaptable to various scenarios such as water and air. Players can perform different operations according to their state in different environments, such as gliding on water and jumping in the air. This cross-scene operational adaptability allows the technical solution provided in this application embodiment to be applied to a wider range of game types and gameplay, such as parkour, competitive, and adventure games.

[0169] The following description continues to illustrate the exemplary structure of the virtual scene vehicle processing device 555 provided in the embodiments of this application as a software module. In some embodiments, as shown in FIG2, the software module stored in the virtual scene vehicle processing device 555 in the memory 550 may include: a display module 5551 and a control module 5552.

[0170] Display module 5551 is configured to display a virtual vehicle carrying a first virtual object in a virtual scene; control module 5552 is configured to control the virtual vehicle to move in a first movement mode adapted to the first area in response to the first virtual object being in a first area of ​​the virtual scene, wherein the type of the first area is any one of the following: air area, ground area and water area.

[0171] In some embodiments, the display module 5551 is further configured to display a virtual scene, wherein the virtual scene includes a first virtual object; the control module 5552 is further configured to, in response to a vehicle summoning operation, maintain the current motion state of the first virtual object, and control a virtual vehicle to appear at the location of the first virtual object and carry the first virtual object.

[0172] In some embodiments, the control module 5552 is further configured to play a first animation in response to the first virtual object being in a moving state, and to control a virtual vehicle to appear at the location of the first virtual object after the first animation has finished playing, wherein the first animation represents the first virtual object in a moving state summoning a virtual vehicle; the control module 5552 is further configured to play a second animation in response to the first virtual object being in a stationary state, and to control a virtual vehicle to appear at the location of the first virtual object after the second animation has finished playing, wherein the second animation represents the first virtual object in a stationary state summoning a virtual vehicle.

[0173] In some embodiments, the control module 5552 is further configured to control the virtual vehicle to turn in response to a steering trigger operation, wherein the steering speed of the virtual vehicle gradually increases as the duration of the steering trigger operation increases.

[0174] In some embodiments, the control module 5552 is further configured to, in response to a deceleration trigger operation, control the virtual vehicle to gradually reduce its moving speed according to a set deceleration rate; and in response to the virtual vehicle's moving speed being less than a first speed threshold, control the virtual vehicle to stop moving.

[0175] In some embodiments, the control module 5552 is further configured to, in response to the virtual vehicle's moving speed being greater than a second speed threshold, control the virtual vehicle to gradually reduce its moving speed according to a set first deceleration; in response to the virtual vehicle's moving speed being less than the second speed threshold but greater than a third speed threshold, control the virtual vehicle to gradually reduce its moving speed according to a set second deceleration, wherein the third speed threshold is less than the second speed threshold; and in response to the virtual vehicle's moving speed being less than the third speed threshold, control the virtual vehicle to gradually reduce its moving speed according to a set third deceleration.

[0176] In some embodiments, the display module 5551 is further configured to display a second virtual object in a virtual scene; the display module 5551 is further configured to display a shooting prop around the first virtual object in response to a shooting trigger operation; and the control module 5552 is further configured to control the shooting prop to shoot at the second virtual object.

[0177] In some embodiments, the control module 5552 is further configured to control the shooting prop to scan a first reference direction of the virtual scene, and in response to the second virtual object moving in the first reference direction, control the sight of the shooting prop to move synchronously in the first reference direction to lock onto the second virtual object; and in response to the first virtual object moving in a second reference direction of the virtual scene, control the shooting prop to move synchronously in the second reference direction.

[0178] In some embodiments, the display module 5551 is further configured to display a shooting control in a virtual scene; the control module 5552 is further configured to, in response to a click operation on the shooting control, display shooting props around the first virtual object and control the shooting props to fire a set number of virtual projectiles at the second virtual object; in response to a press operation on the shooting control, display shooting props around the first virtual object and control the shooting props to continuously fire virtual projectiles at the second virtual object before the press operation is released; wherein, when the second virtual object moves in the virtual scene, the virtual projectiles are controlled to move synchronously to lock the second virtual object.

[0179] In some embodiments, the control module 5552 is further configured to, in response to an attack triggering operation, if there is no second virtual object in the virtual scene, or if the second virtual object in the virtual scene is outside the attack range of the first virtual object, control the first virtual object to perform an attack action in place; the control module 5552 is further configured to, in response to an attack triggering operation, if there is no second virtual object in the virtual scene, control the first virtual object to fall to the ground of the virtual scene and perform an attack action during the fall, when the first virtual object is in an air area.

[0180] In some embodiments, the control module 5552 is further configured to, in response to an attack triggering operation, if a second virtual object is within the attack range of the first virtual object, control the first virtual object to move to the location of the second virtual object at a set moving speed and perform an attack action against the second virtual object when the first virtual object is in a ground area; the control module 5552 is further configured to, in response to an attack triggering operation, if a second virtual object is within the attack range of the first virtual object, control the first virtual object to dive from the air to the location of the second virtual object and perform an air strike action against the second virtual object when the first virtual object is in an air area.

[0181] In some embodiments, the control module 5552 is further configured to control the virtual vehicle to accelerate in response to an acceleration trigger operation on the virtual vehicle; and to control the virtual vehicle to gradually decelerate to the speed before acceleration in response to the acceleration duration reaching a duration threshold.

[0182] In some embodiments, the control module 5552 is further configured to control the virtual vehicle to enter a sprint state in response to a sprint trigger operation for the virtual vehicle; and to control the virtual vehicle to carry the first virtual object to jump in response to a jump trigger operation for the virtual vehicle in the sprint state.

[0183] In some embodiments, the vehicle processing device 555 of the virtual scene further includes a detection module 5553 configured to detect obstacles in the virtual scene in response to an obstacle avoidance triggering operation; and a control module 5552 configured to, when a virtual obstacle is detected in front of the virtual vehicle, and the height of the virtual obstacle is less than a height threshold and the width of the virtual obstacle is less than a width threshold, control the virtual vehicle to perform a vaulting action to cross the virtual obstacle in response to the distance between the virtual vehicle and the virtual obstacle being less than a distance threshold.

[0184] In some embodiments, the control module 5552 is further configured to, when the first virtual object is in the air area of ​​the virtual scene, control the virtual vehicle to switch from a first form to a second form and fly in the air area at a first flight speed during the period when no movement trigger operation for the virtual vehicle is received, wherein the second form and the first form are different forms used to carry the first virtual object; and when the first virtual object is in the air area of ​​the virtual scene, if a movement trigger operation for the virtual vehicle is received, control the virtual vehicle to switch from the second form back to the first form and fly in the air area at a second flight speed, wherein the second flight speed is greater than the first flight speed.

[0185] In some embodiments, the control module 5552 is further configured to, in the event that there is a virtual obstacle in front of the virtual vehicle with a height greater than a height threshold, control the movement direction of the virtual vehicle to automatically adjust to a direction corresponding to the height of the virtual obstacle in response to the distance between the virtual vehicle and the virtual obstacle being less than a distance threshold.

[0186] In some embodiments, the display module 5551 is further configured to cancel the display of the virtual vehicle in the virtual scene in response to the vehicle removal operation; the control module 5552 is further configured to control the first virtual object to continue climbing the virtual obstacle from the position where the virtual vehicle disappeared.

[0187] In some embodiments, the control module 5552 is further configured to control a virtual vehicle to glide in the water area in response to the first virtual object being in the water area of ​​the virtual scene; and to control the virtual vehicle to accelerate in the water area in response to an acceleration trigger operation for the virtual vehicle.

[0188] In some embodiments, the control module 5552 is further configured to control a virtual vehicle to switch from a first movement mode to a second movement mode adapted to the second region in response to a first virtual object entering a second region of a virtual scene from a first region, and the second region being of a different type from the first region.

[0189] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment above, and has similar beneficial effects as the method embodiment, therefore it will not be repeated. For any technical details not covered in the virtual scene vehicle processing apparatus provided in this application embodiment, they can be understood based on the description of any one of Figures 3, 4, or 5.

[0190] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the computer device to perform the virtual scene vehicle processing method described above in this application.

[0191] This application provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor will execute the vehicle processing method for a virtual scene provided in this application, such as the vehicle processing method for a virtual scene shown in FIG3, FIG4, or FIG5.

[0192] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0193] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0194] As an example, executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located in one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0195] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A vehicle processing method for a virtual scene, executed by an electronic device, the method comprising: Display the virtual vehicle carrying the first virtual object in the virtual scene; In response to the first virtual object being located in a first region of the virtual scene, the virtual vehicle is controlled to move in a first movement mode adapted to the first region, wherein the type of the first region is any one of the following: an air region, a ground region, and a water region.

2. The method according to claim 1, wherein, The virtual vehicle displaying the first virtual object in the virtual scene includes: Displaying a virtual scene, wherein the virtual scene includes a first virtual object; In response to a vehicle summoning operation, maintain the current motion state of the first virtual object, and Control the virtual vehicle to appear at the location of the first virtual object and carry the first virtual object.

3. The method according to claim 2, wherein, The control of the virtual vehicle to appear at the location of the first virtual object includes: In response to the first virtual object being in a moving state, a first animation is played, and after the first animation finishes playing, a virtual vehicle is controlled to appear at the location of the first virtual object, wherein the first animation represents the first virtual object in a moving state summoning the virtual vehicle; In response to the first virtual object being in a stationary state, a second animation is played, and after the second animation finishes playing, a virtual vehicle is controlled to appear at the location of the first virtual object, wherein the second animation represents the first virtual object in a stationary state summoning the virtual vehicle.

4. The method according to any one of claims 1 to 3, wherein, The method further includes: In response to a steering trigger operation, the virtual vehicle is controlled to turn, wherein the steering speed of the virtual vehicle gradually increases as the duration of the steering trigger operation increases.

5. The method according to any one of claims 1 to 3, wherein, The method further includes: In response to a deceleration trigger operation, the virtual vehicle is controlled to gradually reduce its speed according to a set deceleration rate; In response to the virtual vehicle's moving speed being less than a first speed threshold, the virtual vehicle is controlled to stop moving.

6. The method according to claim 5, wherein, The control of the virtual vehicle to gradually reduce its speed according to a set deceleration includes: In response to the virtual vehicle's moving speed being greater than a second speed threshold, the virtual vehicle is controlled to gradually reduce its moving speed according to a set first deceleration. In response to the virtual vehicle's movement speed being less than the second speed threshold and greater than the third speed threshold, the virtual vehicle is controlled to gradually reduce its movement speed according to a set second deceleration, wherein the third speed threshold is less than the second speed threshold; In response to the virtual vehicle's movement speed being less than the third speed threshold, the virtual vehicle is controlled to gradually reduce its movement speed according to a set third deceleration.

7. The method according to any one of claims 1 to 6, wherein, The method further includes: Display a second virtual object in the virtual scene; In response to a shooting trigger operation, a shooting prop is displayed around the first virtual object, and the shooting prop is controlled to shoot at the second virtual object.

8. The method according to claim 7, wherein, Before controlling the shooting prop to fire at the second virtual object, the method further includes: The shooting prop is controlled to scan the virtual scene in a first reference direction. In response to the second virtual object moving in the first reference direction, the sight of the shooting prop is controlled to move synchronously in the first reference direction to lock onto the second virtual object. In response to the first virtual object moving in a second reference direction in the virtual scene, the shooting prop is controlled to move synchronously in the second reference direction.

9. The method according to claim 7, wherein, The step of responding to a shooting trigger operation by displaying a shooting prop around the first virtual object and controlling the shooting prop to fire at the second virtual object includes: The shooting controls are displayed in the virtual scene; In response to a click operation on the shooting control, shooting props are displayed around the first virtual object, and the shooting props are controlled to fire a set number of virtual projectiles at the second virtual object; In response to a press operation on the shooting control, a shooting prop is displayed around the first virtual object, and the shooting prop is controlled to continuously fire virtual projectiles at the second virtual object before the press operation is released; When the second virtual object moves in the virtual scene, the virtual launcher is controlled to move synchronously to lock onto the second virtual object.

10. The method according to any one of claims 1 to 9, wherein, The method further includes: When the first virtual object is in the ground area, in response to the attack triggering operation, if there is no second virtual object in the virtual scene, or if the second virtual object in the virtual scene is outside the attack range of the first virtual object, then the first virtual object is controlled to perform the attack action in place. When the first virtual object is in the air area, in response to the attack triggering operation, if there is no second virtual object in the virtual scene, the first virtual object is controlled to fall to the ground of the virtual scene, and an attack action is performed during the fall.

11. The method according to claim 1 or 10, wherein, The method further includes: When the first virtual object is in the ground area, in response to the attack triggering operation, if the second virtual object is within the attack range of the first virtual object, the first virtual object is controlled to move to the position of the second virtual object at a set movement speed, and an attack action is performed on the second virtual object. When the first virtual object is in the airspace, in response to the attack triggering operation, if the second virtual object is within the attack range of the first virtual object, the first virtual object is controlled to dive from the air to the location of the second virtual object, and an air strike is performed on the second virtual object.

12. The method according to any one of claims 1 to 11, wherein, The method further includes: In response to an acceleration trigger operation on the virtual vehicle, control the virtual vehicle to accelerate; In response to the virtual vehicle's acceleration duration reaching a duration threshold, the virtual vehicle is controlled to gradually decelerate back to its original speed before acceleration.

13. The method according to any one of claims 1 to 11, wherein, The method further includes: In response to a sprint trigger operation on the virtual vehicle, the virtual vehicle is controlled to enter a sprint state; In response to a jump trigger operation on the virtual vehicle in the sprint state, the virtual vehicle is controlled to carry the first virtual object to jump.

14. The method according to any one of claims 1 to 11, wherein, The method further includes: In response to the obstacle avoidance trigger operation, obstacle detection is performed in the virtual scene; If a virtual obstacle is detected in front of the virtual vehicle, and the height of the virtual obstacle is less than a height threshold and the width of the virtual obstacle is less than a width threshold, the virtual vehicle is controlled to perform a vaulting action to pass over the virtual obstacle in response to the distance between the virtual vehicle and the virtual obstacle being less than a distance threshold.

15. The method according to any one of claims 1 to 11, wherein, The step of controlling the virtual vehicle to move in a first movement mode adapted to the first region in response to the first virtual object being located in a first region of the virtual scene includes: When the first virtual object is in the air area of ​​the virtual scene, during the period when no movement trigger operation is received for the virtual vehicle, the virtual vehicle is controlled to switch from the first form to the second form and fly in the air area at the first flight speed, wherein the second form and the first form are different forms used to carry the first virtual object; When the first virtual object is in the airspace of the virtual scene, if a movement trigger operation is received for the virtual vehicle, the virtual vehicle is controlled to switch from the second form back to the first form and fly in the airspace at a second flight speed, wherein the second flight speed is greater than the first flight speed.

16. The method according to any one of claims 1 to 11, wherein, The method further includes: When there is a virtual obstacle in front of the virtual vehicle whose height is greater than a height threshold, in response to the distance between the virtual vehicle and the virtual obstacle being less than a distance threshold, the movement direction of the virtual vehicle is automatically adjusted to a direction corresponding to the height of the virtual obstacle.

17. The method according to claim 16, wherein, The method further includes: In response to the vehicle removal operation, the virtual vehicle is de-displayed in the virtual scene, and the first virtual object is controlled to continue climbing the virtual obstacle from the position where the virtual vehicle disappeared.

18. The method according to any one of claims 1 to 11, wherein, The step of controlling the virtual vehicle to move in a first movement mode adapted to the first region in response to the first virtual object being located in a first region of the virtual scene includes: In response to the first virtual object being located in the water surface area of ​​the virtual scene, the virtual vehicle is controlled to glide in the water surface area; The method further includes: In response to an acceleration trigger operation on the virtual vehicle, the virtual vehicle is controlled to accelerate and glide in the water surface area.

19. The method according to any one of claims 1 to 11, wherein, After controlling the virtual vehicle to move in a first movement mode adapted to the first region in response to the first virtual object being located in a first region of the virtual scene, the method further includes: In response to the first virtual object entering the second area of ​​the virtual scene from the first area, and the second area being of a different type from the first area, the virtual vehicle is controlled to switch from the first movement mode to a second movement mode adapted to the second area.

20. The method according to claim 19, wherein, When controlling the virtual vehicle to move in a first movement mode adapted to the first area, the method further includes: Play a first sound effect that is adapted to the first movement mode; After controlling the virtual vehicle to switch from the first movement mode to a second movement mode adapted to the second region, the method further includes: Play a second sound effect that is compatible with the second movement mode.

21. A vehicle processing device for a virtual scene, the device comprising: The display module is configured to display a virtual vehicle carrying the first virtual object in a virtual scene; The control module is configured to control the virtual vehicle to move in a first movement mode adapted to the first area in response to the first virtual object being in a first area of ​​the virtual scene, wherein the type of the first area is any one of the following: an air area, a ground area, and a water area.

22. An electronic device, comprising: Memory is used to store executable instructions for a computer; A processor, configured to execute computer-executable instructions stored in the memory, implements the vehicle processing method of any one of claims 1 to 20 for a virtual scene.

23. A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the vehicle processing method of the virtual scene according to any one of claims 1 to 20.

24. A computer program product comprising a computer program or computer-executable instructions, wherein when the computer program or computer-executable instructions are executed by a processor, the vehicle processing method of the virtual scene according to any one of claims 1 to 20 is implemented.

Images