A method for acquiring a virtual resource and related apparatus

Abstract

This application discloses a method and related apparatus for acquiring virtual resources, showcasing a first virtual scene interface in resource acquisition mode. If the target entity in the entity to be acquired is within a selected range and its initial energy value is greater than a first energy threshold, an animation of continuous acquisition of the target entity is played in response to a acquisition trigger operation. During the playback of the animation of continuous acquisition of the target entity, the initial energy value is deducted as the continuous acquisition progresses to obtain a real-time energy value. As long as the real-time energy value is greater than the first energy threshold, continuous acquisition continues until the continuous acquisition progress indicates acquisition completion. When the continuous acquisition progress indicates acquisition completion, the virtual resource corresponding to the target entity is acquired. Thus, by dynamically limiting continuous acquisition based on energy values, unlimited acquisition of virtual resources in a short period is avoided, resulting in a more dynamic and engaging experience while reducing computational resource consumption.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and related apparatus for acquiring virtual resources. Background Technology

[0002] With the rapid popularization of virtual reality, metaverse, open-world games, and virtual building applications, virtual scenes typically contain a large number of interactive entities, such as building materials, tables and chairs, decorative components, and scene props. Users' actions in building, crafting, and upgrading within virtual scenes heavily rely on acquiring and utilizing the virtual resources corresponding to these entities. Therefore, it is necessary to acquire the virtual resources corresponding to these entities.

[0003] In related technologies, the methods for obtaining virtual resources often employ simple acquisition logic. Typically, users can obtain the virtual resources corresponding to an entity by clicking on the entity in the virtual scene.

[0004] However, this method lacks tension and strategic depth in the process. At the same time, because users can click on entities without limit in a short period of time to obtain virtual resources, the pace of obtaining virtual resources is too flat, which can easily lead to experience fatigue in long-term participation and consume too many computing resources. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method and related apparatus for acquiring virtual resources, which enhances the sense of urgency and strategic depth during the virtual resource acquisition process and reduces computational resource consumption.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] On one hand, embodiments of this application provide a method for obtaining virtual resources, the method comprising:

[0008] The first virtual scene interface, which is in resource acquisition mode, is displayed. The first virtual scene interface includes the initial energy value and the entity to be acquired.

[0009] If the target entity in the entity to be acquired is within the selected range, and the initial energy value is greater than the first energy threshold, in response to the acquisition trigger operation, an animation of continuous acquisition of the target entity is played;

[0010] During the playback of the animation of continuous acquisition of the target entity, the initial energy value is subtracted to obtain a real-time energy value as the continuous acquisition progresses, and the continuous acquisition continues to be executed until the continuous acquisition progress is completed when the real-time energy value is greater than the first energy threshold.

[0011] When the continuous data collection is completed, the virtual resources corresponding to the target entity are acquired.

[0012] On the one hand, embodiments of this application provide a virtual resource acquisition device, the device including a display unit, a playback unit, a deduction unit, and an acquisition unit;

[0013] The display unit is used to display a first virtual scene interface in resource acquisition mode, the first virtual scene interface including an initial energy value and an entity to be acquired;

[0014] The playback unit is configured to play an animation of continuous acquisition of the target entity in response to a acquisition trigger operation if the target entity in the entity to be acquired is within the selected range and the initial energy value is greater than the first energy threshold.

[0015] The deduction unit is used to subtract the initial energy value to obtain a real-time energy value as the continuous acquisition progresses during the playback of the animation of performing continuous acquisition on the target entity, and when the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the continuous acquisition progress is acquisition completion.

[0016] The acquisition unit is used to acquire the virtual resources corresponding to the target entity when the progress of the continuous acquisition is completed.

[0017] On one hand, embodiments of this application provide a computer device, the computer device including a processor and a memory:

[0018] The memory is used to store computer programs and to transfer the computer programs to the processor;

[0019] The processor is configured to execute the method described in any of the foregoing aspects according to instructions in the computer program.

[0020] In one aspect, embodiments of this application provide a computer-readable storage medium for storing a computer program that, when executed by a processor, causes the processor to perform the methods described in any of the foregoing aspects.

[0021] On one hand, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the foregoing aspects.

[0022] As can be seen from the above technical solution, when virtual resources need to be acquired, this application can display a first virtual scene interface in resource acquisition mode. The first virtual scene interface includes an initial energy value and entities to be acquired. If the target entity among the entities to be acquired is within the selected range, it means that the target entity can be acquired. When the user wants to acquire the target entity, a acquisition trigger operation can be executed. This application links entity acquisition with the real-time deduction process of energy value. Entity acquisition requires energy value. Therefore, only when the initial energy value is greater than a first energy threshold can there be energy to acquire entities, and only then can the acquisition trigger operation be responded to to perform continuous acquisition of the target entity, playing an animation of continuous acquisition of the target entity. During the playback of the animation of continuous acquisition of the target entity, the initial energy value is deducted as the continuous acquisition progresses to obtain a real-time energy value. When the real-time energy value is greater than the first energy threshold, continuous acquisition continues until the continuous acquisition progress is acquisition complete. When the continuous acquisition progress is acquisition complete, the virtual resource corresponding to the target entity can be acquired, completing the acquisition of the virtual resource. This application links entity acquisition with the real-time deduction of energy values, thereby increasing the sense of urgency and strategic depth in virtual resource acquisition. Simultaneously, this application implements a dynamic constraint mechanism for virtual resource acquisition; that is, continuous entity acquisition requires a certain amount of energy, and as energy is depleted, it becomes difficult to consistently meet the requirements. This avoids unlimited acquisition of virtual resources in a short period, resulting in a more dynamic and immersive experience, reducing the likelihood of user fatigue. Furthermore, because unlimited acquisition of virtual resources is avoided, unlimited data refreshes are prevented, thus reducing computational resource consumption. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 An architecture diagram of a computer system provided in this application embodiment;

[0025] Figure 2 An application scenario architecture diagram for a method of acquiring virtual resources provided in an embodiment of this application;

[0026] Figure 3 A schematic diagram of an application scenario for a method for obtaining virtual resources provided in this application embodiment;

[0027] Figure 4A flowchart illustrating a method for acquiring virtual resources provided in an embodiment of this application;

[0028] Figure 5 A schematic diagram illustrating a fatigue state based on real-time energy values ​​provided in an embodiment of this application;

[0029] Figure 6 A schematic diagram illustrating a normal real-time energy value provided in an embodiment of this application;

[0030] Figure 7 A schematic diagram illustrating a locked state for real-time energy values ​​provided in an embodiment of this application;

[0031] Figure 8 A schematic diagram of an energy progress bar provided in an embodiment of this application;

[0032] Figure 9 One of the schematic diagrams of a native segment progress bar and an added segment progress bar provided in the embodiments of this application;

[0033] Figure 10 A second schematic diagram illustrating a native segment progress bar and an added segment progress bar, provided for embodiments of this application;

[0034] Figure 11 A schematic diagram of a crosshair indicator provided in an embodiment of this application;

[0035] Figure 12 A schematic diagram of a crosshair indicator in an unaimed state provided in an embodiment of this application;

[0036] Figure 13 A schematic diagram of a crosshair indicator in the acquisition process, provided for an embodiment of this application;

[0037] Figure 14 A schematic diagram of a crosshair indicator in a locked state provided in an embodiment of this application;

[0038] Figure 15 This is a schematic diagram illustrating the display of a first prompt message, provided as an embodiment of this application.

[0039] Figure 16 This is a schematic diagram illustrating the display of entity information provided in an embodiment of this application;

[0040] Figure 17 A schematic diagram illustrating an entity displaying a high-quality level, provided as an embodiment of this application;

[0041] Figure 18 This application provides a schematic diagram illustrating the display of multiple second prompt messages in an embodiment.

[0042] Figure 19A schematic diagram of a special jump character provided for an embodiment of this application;

[0043] Figure 20 A schematic diagram illustrating a claimable status marker provided in an embodiment of this application;

[0044] Figure 21 A schematic diagram of a game map interface provided in an embodiment of this application;

[0045] Figure 22 A schematic diagram illustrating a details pop-up window provided in an embodiment of this application;

[0046] Figure 23 A schematic diagram of a second virtual scene interface provided for an embodiment of this application;

[0047] Figure 24 A schematic diagram of a hardware environment provided for an embodiment of this application;

[0048] Figure 25 A schematic diagram of a background process provided for an embodiment of this application;

[0049] Figure 26 A structural diagram of a virtual resource acquisition device provided in an embodiment of this application;

[0050] Figure 27 A structural diagram of a terminal provided in an embodiment of this application;

[0051] Figure 28 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0052] The embodiments of this application will now be described with reference to the accompanying drawings.

[0053] In related technologies, the methods for obtaining virtual resources are usually relatively simple. The following describes three methods:

[0054] Method 1: Single-click acquisition mode.

[0055] Users can select entities in a virtual scene through a single trigger operation such as clicking, touching, or pressing a button. After receiving this single trigger operation, the terminal directly executes the resource acquisition logic, writes the virtual resource corresponding to the selected entity into the memory, and displays the resource acquisition result on the interface. In other words, in acquisition method one, the user's interaction with the entity is usually manifested as a single trigger and a single settlement, and the virtual resource acquisition process can be completed instantly.

[0056] Method 2: Automatic timed acquisition mode.

[0057] Users can pre-place the data collection device at the target location. The game system automatically executes the resource production logic at preset time intervals and updates the user's corresponding resource data after the time conditions are met. In the second acquisition method, users do not need to continuously participate in each resource acquisition process; instead, they accumulate virtual resources by waiting for the game system to periodically produce them. In other words, the second acquisition method lacks a continuous interaction process between the user and the entity.

[0058] In addition, the above acquisition methods allow users to acquire virtual resources without restriction. Not only is the acquisition pace too flat, which can easily lead to user fatigue after long-term participation, but the relevant data and display content of virtual resources are also refreshed frequently, resulting in continuous data updates and content rendering, which can easily increase the consumption of computing resources.

[0059] To address the aforementioned technical problems, this application provides a method and related apparatus for acquiring virtual resources. By adjusting the virtual resource acquisition process to a continuous acquisition process constrained by energy values, users need to consider not only whether the target entity is within the selected range but also whether the current energy value is sufficient to support the acquisition process. This increases the sense of urgency and strategic depth in the virtual resource acquisition process. Simultaneously, since continuous acquisition consumes energy values, it prevents users from continuously and without restriction acquiring virtual resources in a short period, reducing the consumption of computing resources.

[0060] It should be noted that the method for acquiring virtual resources provided in this application can be applied to various scenarios that require acquiring virtual resources, such as virtual reality scenarios, metaverse scenarios, open-world game scenarios, and virtual construction applications. The following scenarios are briefly described:

[0061] (a) Virtual Reality Scenarios:

[0062] In virtual reality scenarios, users typically enter an immersive virtual environment through input devices such as head-mounted displays, controllers, and motion-sensing devices, and interact with entities within that environment. For example, in virtual training, exploration, or exhibition scenarios, users can collect entities such as materials, energy bodies, props, or task items to obtain corresponding virtual resources. If virtual resources are directly acquired through a single click or simple trigger, the user's operation in the immersive environment feels abrupt and lacks a sense of immersion in resource acquisition. Therefore, the virtual resource acquisition method provided in this application's embodiments allows for continuous acquisition of entities after the user selects an entity and triggers the acquisition operation, while simultaneously deducting energy values ​​during the acquisition process. This enables users to perceive the acquisition process and energy consumption within the virtual reality scenario, thereby enhancing the immersiveness and strategic nature of virtual resource acquisition in the virtual reality environment.

[0063] (II) Metaverse Scene:

[0064] In the metaverse scenario, users can enter a shared virtual space through virtual avatars and engage in activities such as exploration, social interaction, trading, and virtual asset accumulation. The metaverse scenario typically contains numerous interactive entities, such as virtual materials, decorative resources, quest items, and event reward resources. If users could continuously acquire the virtual resources corresponding to these entities without restriction, the acquisition pace would be too rapid, reducing the acquisition value of the virtual resources themselves and the sense of interactive participation. Therefore, the virtual resource acquisition method provided in this application's embodiments links the acquisition process to energy values. This requires users to continuously perform collection operations on entities in the metaverse when acquiring virtual resources, and collection can only be completed when the energy value meets certain conditions. This creates an energy-constrained virtual resource acquisition pace in the metaverse scenario, preventing users from acquiring virtual resources without restriction in a short period and improving the sense of participation, rhythm, and controllability of the virtual resource acquisition process.

[0065] (III) Open-world game scenarios:

[0066] In open-world game scenarios, the virtual environment is vast, typically containing numerous obtainable entities such as ores, plants, building materials, energy shards, and quest items. Users need to continuously discover, select, and collect these entities during exploration to progress in character development, equipment crafting, map exploration, or quest advancement. If a single-click acquisition mode is used, users can quickly acquire a large number of virtual resources by clicking repeatedly, resulting in a lack of process feedback and strategic choice in the resource acquisition process. Therefore, the virtual resource acquisition method provided in this application, after the user enters resource acquisition mode, controls whether continuous collection can be initiated based on whether the target entity is within the selected range and whether the current energy value is greater than a first energy threshold. Energy is deducted in real-time during continuous collection, thus creating an interactive process in open-world games where target selection, continuous collection, energy consumption, and collection completion are interconnected, thereby increasing the tension and strategic depth of resource acquisition.

[0067] (iv) Virtual construction application scenarios:

[0068] In virtual construction applications, users typically need to acquire physical entities such as building materials, decorative parts, and functional components within a virtual scene, and then utilize the corresponding virtual resources to complete operations such as building houses, arranging scenes, upgrading facilities, and modifying spaces. Since the construction process often requires a large amount of virtual resources, if the acquisition method is too simple, users may acquire a large number of virtual resources in a short period through continuous triggering of operations, leading to frequent updates of resource data and frequent refreshes of scene display content, thus diminishing the sense of accomplishment in acquiring construction resources. Therefore, the virtual resource acquisition method provided in this application embodiment sets the acquisition process of virtual resources required for construction as a continuous acquisition process, and limits the acquisition process through energy values. This avoids the high-frequency refresh of resource data and interface content caused by unlimited acquisition of construction resources in a short period, thereby reducing the consumption of computing and rendering resources.

[0069] It should be noted that the method for obtaining virtual resources provided in this application embodiment can be executed by a computer device, which can be a terminal, a server, or both.

[0070] To facilitate understanding of the virtual resource acquisition method provided in the embodiments of this application, the computer system used to implement the virtual resource acquisition method will be described exemplarily below.

[0071] See Figure 1 , Figure 1 An architecture diagram of a computer system provided in an embodiment of this application. Figure 1 The computer system 100 described herein is a system architecture for implementing the virtual resource acquisition method in the embodiments of this application. The computer system 100 includes a terminal 120 and a server 140.

[0072] A virtual resource acquisition client can be installed and run on terminal 120, through which virtual resources can be acquired. This virtual resource acquisition client may be, for example, an application (App) or mini-program on terminal 120, or even a webpage. This embodiment of the application does not limit the form of the virtual resource acquisition client in any way.

[0073] It should be noted that a client with virtual resource acquisition capabilities can function as a virtual resource acquisition client. For example, in a game scenario, a virtual resource acquisition client can be a game client. Similarly, in a virtual reality scenario, a virtual resource acquisition client can be a virtual reality application client.

[0074] Terminal 120 can be a terminal used by a user. The virtual resource acquisition client running in terminal 120 can provide an interactive interface, through which the user can trigger the acquisition of virtual resources.

[0075] Terminal 120 can refer to one of multiple terminals, and this application embodiment only uses terminal 120 as an example. The device types of terminal 120 include, but are not limited to, at least one of the following: in-vehicle terminal, smartphone, tablet computer, computer, intelligent voice interaction device, smart home appliance, aircraft, wearable device, personal computer (PC), laptop computer, and desktop computer. Those skilled in the art will understand that the number of terminals 120 can be more or less. For example, there may be only one terminal 120, or there may be multiple or more terminals 120. This application embodiment does not limit the number or device type of terminal 120.

[0076] Terminal 120 can connect to server 140 via a network for network communication. This network can be a wireless network or a wired network. The network uses standard communication technologies and / or protocols, typically the Internet, but can also be any network, including but not limited to Bluetooth, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), mobile, private networks, or any combination of virtual private networks. In some embodiments, customized or dedicated data communication technologies may be used to replace or supplement the aforementioned data communication technologies.

[0077] Server 140 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud servers, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0078] For example, server 140 is used to provide virtual resource acquisition services for a virtual resource acquisition client running on terminal 120. Server 140 includes processor 144 and memory 142. Memory 142 is used to store related computer programs, such as computer programs related to the background services to be provided. Processor 144 is used to execute the computer programs stored in memory 142 to provide corresponding virtual resource acquisition services for virtual resource acquisition. For example, processor 144 is used to acquire a signal that triggers entry into a first virtual scene interface in resource acquisition mode, and render the first virtual scene interface in resource acquisition mode based on the signal. The first virtual scene interface includes an initial energy value and an entity to be acquired. Processor 144 is also used to determine whether the target entity in the entity to be acquired is within a selected range (e.g., by performing an intersection of a ray and the target entity), and if the target entity is within the selected range and the initial energy value is greater than a first energy threshold, in response to the acquisition trigger operation, to render an animation of continuous acquisition of the target entity. During continuous data acquisition, processor 144 deducts the initial energy value as the acquisition progresses to obtain a real-time energy value. When the real-time energy value exceeds a first energy threshold, it continues to execute the background business logic for continuous data acquisition and renders the continuous acquisition animation until the acquisition is complete. When the acquisition is complete, processor 144 updates the user's background data to represent the virtual resources corresponding to the target entity.

[0079] Optionally, server 140 undertakes the main computing work and terminal 120 undertakes the secondary computing work; or, server 140 undertakes the secondary computing work and terminal 120 undertakes the main computing work; or, server 140 and terminal 120 adopt a distributed computing architecture for collaborative computing.

[0080] The application scenarios of the virtual resource acquisition method provided in the embodiments of this application will be described below with reference to the accompanying drawings. For example... Figure 2 As shown, Figure 2 An application scenario architecture diagram of a method for acquiring virtual resources is shown. This application scenario may include a terminal 21 and a server 22.

[0081] Terminal 21 can be a user-operated terminal, on which a virtual resource acquisition client can run. Server 22 can act as a backend server for the virtual resource acquisition client, supporting terminal 21 in executing the virtual resource acquisition method. See also Figure 3 , Figure 3 A schematic diagram illustrating an application scenario of a method for acquiring virtual resources is provided. To facilitate understanding of the execution of terminal 21 in this embodiment, the following is a detailed explanation... Figure 2 and Figure 3The application scenarios provided by the embodiments of this application will be explained through steps 1-4.

[0082] In step 1, when a user wishes to acquire virtual resources in a virtual scene, the user can enter resource acquisition mode through a virtual resource acquisition client running on terminal 21. For example, the user can execute the operation of entering resource acquisition mode on terminal 21, and then terminal 21 responds to the operation of entering resource acquisition mode by displaying a first virtual scene interface in resource acquisition mode. The first virtual scene interface includes an initial energy value and entities to be acquired. The number of entities to be acquired can be multiple, and the initial energy value can be represented by an energy progress bar.

[0083] like Figure 3 As shown, the first virtual scene interface includes entities 23, 24, and 25 to be acquired, and an energy progress bar for displaying the initial energy value, which indicates that the initial energy value is 60. The relevant data required to generate the first virtual scene interface can be obtained by the terminal 21 requesting data from the server 22. For example, the terminal 21 generates a request based on entering resource acquisition mode and sends the request to the server 22 to obtain relevant data. For instance, the initial energy value can be obtained by the terminal 21 requesting data from the server 22; the entities to be acquired can be rendered by the terminal 21 in the first virtual scene interface based on the entity configuration data sent by the server 22. Furthermore, the first virtual scene interface also displays a selected area, which the user can move through the terminal 21 to select the target entity.

[0084] In step 2, if the target entity in the entity to be acquired is within the selected range and the initial energy value is greater than the first energy threshold, in response to the acquisition trigger operation, the terminal 21 plays an animation of continuous acquisition of the target entity.

[0085] like Figure 3 As shown, taking the entity to be acquired 24 as the target entity selected by the user as an example, after displaying the first virtual scene interface, the terminal 21 can determine whether the entity to be acquired 24 (i.e., the target entity) is within the selected range. If the target entity is within the selected range, and the terminal 21 determines that the initial energy value is greater than the first energy threshold (0 in this embodiment), it indicates that the conditions for performing acquisition on the target entity are met. At this time, if the terminal 21 receives an acquisition trigger operation performed by the user, such as... Figure 3As shown, the selected identifier stays on the entity to be acquired 24. In response to the acquisition trigger operation, terminal 21 plays an animation of continuous acquisition of entity 24. Entity 24 gets closer and closer to the user's viewpoint, and displays "Acquiring...". The animation for generating the first continuous acquisition can be obtained by terminal 21 after requesting it from server 22. For example, terminal 21 generates a request based on the acquisition trigger operation and sends the request to server 22 to obtain the animation from server 22.

[0086] In step 3, during the process of playing the animation of continuous acquisition of the target entity on the terminal 21, the initial energy value is deducted as the continuous acquisition progresses to obtain the real-time energy value. When the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the continuous acquisition progress is completed.

[0087] like Figure 3 As shown, during the continuous acquisition process, the initial energy value is continuously subtracted to obtain the real-time energy value. At a certain moment, the obtained real-time energy value can be 40.

[0088] If the real-time energy value is greater than the first energy threshold, the terminal 21 continues to play the animation of continuous acquisition of the target entity, so that the continuous acquisition continues to be executed until the continuous acquisition progress reaches the acquisition completion.

[0089] During the continuous data collection process, server 22 can perform background logic to deduct energy values ​​and send the real-time energy value obtained from the energy deduction to terminal 21.

[0090] In step 4, when the continuous collection progress reaches the collection completion stage, terminal 21 acquires the virtual resources corresponding to the target entity.

[0091] like Figure 3 As shown, when the data collection is complete, the real-time energy value is reduced to 20, the entity 24 to be acquired disappears, and an animation of "Data collection complete, leaf acquired" is displayed. During this process, the server 22 can send the animation to be played when the data collection is complete to the terminal 21 so that the terminal 21 can play the animation indicating that the data collection is complete.

[0092] By linking entity acquisition with the real-time deduction of energy values ​​using the aforementioned method, the sense of urgency and strategic depth in acquiring virtual resources is enhanced. The energy value deduction mechanism dynamically limits the acquisition of virtual resources, creating a more dynamic and engaging experience, reducing the likelihood of user fatigue, and decreasing computational resource consumption.

[0093] It should be noted that in the specific implementation of this application, the entire process may involve user information and other related data. When the above embodiments of this application are applied to specific products or technologies, separate consent or permission from the user is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0094] Next, taking a computer device as the terminal as an example, the method for obtaining virtual resources provided in the embodiments of this application will be described in detail with reference to the accompanying drawings. See also Figure 4 , Figure 4 A flowchart of a method for acquiring virtual resources is shown, the method including steps S401-S404, as detailed below:

[0095] S401: Displays the first virtual scene interface in resource acquisition mode.

[0096] In this embodiment of the application, virtual resources are a type of data object that can be acquired, accumulated, consumed, exchanged, synthesized, constructed, upgraded, or trigger other virtual interaction results in a virtual scene.

[0097] For example, in virtual construction applications, virtual resources may include wood resources, stone resources, metal resources, cloth resources, decorative component resources, building component resources, etc.; in open-world games, virtual resources may include plant resources, mineral resources, energy resources, exploration item resources, quest progression resources, etc.; in virtual reality or metaverse applications, virtual resources may include space decoration resources, interactive prop resources, virtual asset fragments, activity resources, scene modification resources, etc. This application does not specifically limit the resource type, resource purpose, or resource data structure of virtual resources; as long as they can be obtained by collecting data from entities in a virtual scene, they can be used as virtual resources in this application's embodiments.

[0098] A virtual scene refers to a virtual environment displayed (or provided) by an application while it is running on a computer device. This virtual environment can be a simulation of the real world, a semi-simulated / semi-fictional three-dimensional environment, or a purely fictional three-dimensional environment. The virtual environment can be any of a two-dimensional, 2.5-dimensional, or three-dimensional virtual environment. A virtual scene may include terrain, buildings, props, characters, decorations, resource points, floating objects, functional areas, collection areas, etc. It should be noted that the virtual scene in this embodiment is not limited to a game scene; it can also be other interactive scenes with virtual resources.

[0099] Resource acquisition mode is an interaction mode within a virtual scene, indicating that the current user can perform virtual resource acquisition operations on entities within the virtual scene. In resource acquisition mode, the terminal can display entities that can be acquired.

[0100] This application does not limit how the resource acquisition mode is entered. As one implementation, the resource acquisition mode can be an interaction mode triggered after a user enters a specific area; as another implementation, the resource acquisition mode can be an interaction mode entered after a user triggers a function entry point; and as yet another implementation, the resource acquisition mode can be an interaction mode switched to after detecting that the user meets the resource acquisition conditions.

[0101] The first virtual scene interface is the virtual scene interface displayed in resource acquisition mode. The first virtual scene interface can be a complete virtual scene image or a partial image of a virtual scene. The first virtual scene interface can be a first-person perspective interface, a third-person perspective interface, a top-down perspective interface, a free-viewpoint interface, or a hybrid perspective interface; it can be an interface rendered locally on the terminal, or an interface displayed on the terminal after the server generates the screen data. This application embodiment does not specifically limit the above content.

[0102] In this embodiment, virtual resources can be obtained by collecting data from entities. An entity is an object in a virtual scene that corresponds to a virtual resource. For example, the entity itself may be the virtual resource to be acquired. Alternatively, if an entity is an interactive object in a virtual scene, collecting data from the entity allows obtaining the corresponding virtual resource based on the correspondence between the entity and the virtual resource.

[0103] The entity to be acquired is an entity that has not yet been captured in the first virtual scene interface. The entity to be acquired can be a single entity or multiple entities; it can be a static entity or a dynamic entity; it can be an entity fixed in the virtual scene, or an entity that moves, floats, refreshes, or appears periodically in the virtual scene.

[0104] The relationship between the entity to be acquired and the virtual resource can be one-to-one, one-to-many, or many-to-one. For example, one entity to be acquired can correspond to one type of virtual resource or multiple types of virtual resources; multiple entities to be acquired can also correspond to different quantities of the same type of virtual resource.

[0105] The first virtual scene interface includes an initial energy value and the entity to be acquired. The energy value is a numerical parameter used to constrain the virtual resource acquisition process, representing the capability to support the execution of the acquisition process. The initial energy value is the energy value before the acquisition of the target entity is performed.

[0106] For example, the initial energy value can be the energy value read when entering resource acquisition mode, the energy value read when the user selects a target entity, or the energy value most recently updated before the user performs the acquisition trigger operation. This application does not specifically limit the numerical range or display format of the energy value.

[0107] For example, energy values ​​can be displayed through numerical values, scales, graphics, icons, colors, textures, animations, or combinations thereof.

[0108] As one implementation method, the energy value can be displayed in digital form, for example, as a specific value such as 60, 80, 100, or as a combination of the current energy value and the energy limit value such as 60 / 100, 80 / 120.

[0109] As another way of implementation, the energy value can be displayed as a percentage, such as 60%, 80%, etc.

[0110] As another implementation method, energy values ​​can be displayed through progress-type graphics, such as bar progress, ring progress, fan progress, circular dashboard, scale groove, segmented grid, energy column, and energy ball filling degree to reflect the current remaining energy.

[0111] As another implementation method, the energy value can be displayed by the number of icons. For example, multiple battery icons, crystal icons, star icons, flame icons, droplet icons, energy core icons, etc. can be displayed to indicate the remaining energy units.

[0112] As another implementation method, the energy value can be displayed through changes in the appearance of the virtual acquisition device. For example, the brightness, luminous range, shell integrity, energy texture density, particle swirling intensity, and mechanical component deployment of the virtual acquisition device can change with the energy value.

[0113] As another implementation method, energy value can be displayed through the interface background or the status of interactive controls. For example, the brightness of the control border, the fill level of the collection button, the energy indicator in the corner of the interface, and the prompt light effect of the character's handheld device can reflect the current energy status.

[0114] As another implementation method, energy values ​​can be represented by text prompts or voice prompts, such as displaying prompts that the current available energy is sufficient, the current remaining energy is low, or the remaining collection capacity is insufficient.

[0115] In this embodiment of the application, the terminal displays a first virtual scene interface in resource acquisition mode, so that the user can see the initial energy value used to start the acquisition process and the entities to be acquired that can be acquired in the first virtual scene interface.

[0116] Therefore, by displaying the first virtual scene interface in resource acquisition mode, users can determine which entities are available for acquisition based on the first virtual scene interface, and can also judge whether they have the basic ability to perform acquisition based on the initial energy value, thus providing guidance for subsequent acquisition of target entities.

[0117] S402: If the target entity in the entity to be acquired is within the selected range and the initial energy value is greater than the first energy threshold, in response to the acquisition trigger operation, play an animation of continuous acquisition of the target entity.

[0118] The target entity is an entity to be acquired. The selected range is the area used to determine whether the entity can be acquired. The range can be the screen area, distance range, angle range, collision range, object selection range, or other ranges that can be used to determine whether an entity is selected. The selected range can be preset or dynamically determined based on the user's viewpoint, position, operation method, device type, scene type, entity type, etc.

[0119] For example, the selected range can be an area within a certain distance around the user character, an interactive area near the center of the screen, a selection area corresponding to an input control, an interactive area facing the virtual camera, an object selection area corresponding to the position of a controller, touch point, or mouse, or a spatial area pointed to by the virtual reality controller.

[0120] The first energy threshold is used to determine whether the initial energy value is sufficient to start the data acquisition process. The first energy threshold can be fixed or dynamically determined based on the application scenario, entity type, data acquisition difficulty, user level, and resource acquisition mode.

[0121] For example, the first energy threshold can be 0, indicating that data acquisition can be started as long as the current energy value is greater than 0. The first energy threshold can also be a value greater than 0, indicating that data acquisition is only allowed to start when the current energy value exceeds a certain margin.

[0122] A data acquisition trigger is an action performed by the user to initiate the acquisition of a target entity. Data acquisition triggers can be generated through touchscreens, mice, keyboards, gamepads, motion-sensing devices, virtual reality controllers, voice input devices, or other input devices. Data acquisition triggers can include clicks, presses, swipes, drags, gestures, shortcut keys, controller triggers, key combinations, or other input actions that can trigger the data acquisition process.

[0123] Continuous acquisition is used to indicate that acquisition of a target entity is ongoing, and the target entity has not been fully acquired until the acquisition process reaches the completion stage. That is, there is a continuous and gradual process between the target entity's acquireable state and its acquisition-completed state, rather than the resource acquisition being completed immediately after the acquisition is triggered.

[0124] The animation for continuously collecting data on the target entity is the animation content used to represent the continuous collection process in the first virtual scene interface. For example, the animation can show the target entity gradually approaching, gradually shrinking, gradually decomposing, gradually dissipating, gradually lighting up, gradually being pulled, gradually being extracted, gradually transforming into a resource form, gradually entering the user-side area, or gradually being removed from the virtual scene. It can also be indicated by text display that continuous collection is in progress.

[0125] Specifically, if the target entity in the entity to be acquired is within the selected range, it means that the target entity can be acquired. When the user wishes to acquire the target entity, a acquisition trigger operation can be executed. After determining that the target entity is within the selected range and the initial energy value is greater than the first energy threshold, the terminal responds to the acquisition trigger operation by playing an animation of continuous acquisition of the target entity. That is to say, in this embodiment, unlike the direct acquisition of the target entity as soon as the user initiates the acquisition trigger operation, two preconditions must be met simultaneously:

[0126] The first prerequisite is that the target entity is within the selected range, indicating that the current target entity is an object that can be collected.

[0127] The second prerequisite is that the initial energy value is greater than the first energy threshold, indicating that the energy conditions for initiating the acquisition process are met. Only when both prerequisites are satisfied will the terminal respond to the acquisition trigger operation, enabling the target entity to enter the continuous acquisition process.

[0128] In other words, the first virtual scene interface can include at least one entity to be acquired. The terminal can determine the target entity from multiple entities and judge whether the target entity is within the selected range. If the target entity is not within the selected range, continuous acquisition of the target entity will not be initiated even if the user executes the acquisition trigger operation. If the target entity is within the selected range, but the initial energy value is less than or equal to the first energy threshold, it indicates that the current energy condition is insufficient, and continuous acquisition of the target entity will not be initiated. If the target entity is within the selected range and the initial energy value is greater than the first energy threshold, the terminal responds to the acquisition trigger operation by playing an animation of continuous acquisition of the target entity.

[0129] S403: During the playback of the animation of continuous acquisition of the target entity, the initial energy value is deducted as the continuous acquisition progresses to obtain the real-time energy value. When the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the continuous acquisition progress is completed.

[0130] The progress of continuous data acquisition is used to characterize the advancement of the continuous data acquisition process. The progress can be a percentage, stage, time, cumulative acquisition amount, acquisition completion rate, animation playback progress, or other data that can characterize whether continuous data acquisition is complete. For example, the acquisition progress can advance from 0 to 100%, from the first stage to the final stage, or from the initial acquisition amount to the target acquisition amount. The progress of continuous data acquisition can be consistent with the playback progress of the continuous data acquisition animation, or there can be a mapping relationship between them. For example, when the animation is halfway through, the progress of continuous data acquisition can be 50%; or, when the target entity completes multiple stages of change, each stage of change corresponds to a range of acquisition progress.

[0131] Energy value deduction refers to the process of reducing energy values ​​based on the progress of continuous data collection during the continuous data collection process.

[0132] The embodiments of this application do not specifically limit the frequency of energy value deduction. For example, it can be deducted in segments according to the progress interval of continuous data collection, or it can be deducted continuously according to the change in the progress of continuous data collection.

[0133] For example, when the collection progress increases from 0% to 30%, the initial energy value can be reduced by the first part of the energy; when the collection progress increases from 30% to 70%, the second part of the energy can be reduced; and when the collection progress increases from 70% to completion, the third part of the energy can be reduced. Alternatively, for each unit increase in collection progress, the energy value can be reduced by at least one unit. After each collection stage, the energy value can be updated according to the reduction rules corresponding to that stage.

[0134] The real-time energy value is the energy value obtained after deducting the initial energy value during continuous data acquisition. Since continuous data acquisition is ongoing, the real-time energy value changes as the acquisition progresses. The real-time energy value can be used to determine whether the energy conditions for continuing continuous data acquisition are still met. For example, if the initial energy value is 60, the real-time energy value may become 50 after continuous data acquisition has progressed to a certain point.

[0135] The "collection complete" indicator signifies that the continuous data collection process has ended. This application does not specifically limit the criteria for determining collection completion; for example, collection completion could mean that the collection progress has reached a preset completion progress, or that all collectable data of the target entity has been collected. For instance, reaching 100% collection progress can indicate that collection is complete.

[0136] Specifically, during the playback of the animation demonstrating continuous data acquisition of the target entity, the terminal deducts the initial energy value as the acquisition progresses, resulting in a real-time energy value. In other words, the continuous acquisition process is not merely a wait for the animation to finish, but a process linked to changes in the energy value. As the continuous acquisition of the target entity continues, the initial energy value is gradually deducted, and the real-time energy value changes accordingly.

[0137] Furthermore, as long as the real-time energy value is greater than the first energy threshold, continuous data acquisition continues until the continuous acquisition progresses to completion. In other words, a real-time energy value greater than the first energy threshold is a condition for continuous acquisition to continue progressing towards completion. As long as the real-time energy value remains greater than the first energy threshold, it indicates that the energy conditions required for continuous acquisition are still met, and the terminal can continue playing the animation of continuous acquisition of the target entity and continue to advance the continuous acquisition progress until the continuous acquisition progress reaches completion.

[0138] It should be noted that, in this embodiment, the energy value during continuous data acquisition is not determined only once before the acquisition begins, nor is it deducted only once after the acquisition is completed. Instead, the energy value is deducted continuously throughout the acquisition process, and the real-time energy value continues to affect whether the continuous acquisition process can continue until completion. Therefore, a continuous correlation is formed between the energy value and the continuous acquisition process of the target entity.

[0139] Therefore, by deducting energy values ​​as continuous collection progresses, and using whether the real-time energy value exceeds a first energy threshold as the condition for continuing continuous collection, the acquisition of virtual resources can be constrained by energy values. When a user performs collection on a target entity, they not only need to input a collection trigger operation but also consume energy values ​​during the continuous collection process. Collection can only continue until completion if the real-time energy value still meets the condition. This avoids the instantaneous acquisition of virtual resources after the user triggers an operation, making the virtual resource acquisition process more immersive. Simultaneously, because energy values ​​are deducted as continuous collection progresses, users cannot continuously collect a large number of target entities in a short period, creating fluctuations in the resource acquisition rhythm and reducing user fatigue caused by long-term repetitive collection.

[0140] S404: When the continuous data collection progress reaches the completion stage, acquire the virtual resources corresponding to the target entity.

[0141] When the continuous data collection progress reaches the completion stage, it indicates that the target entity has undergone a complete continuous data collection process, and the virtual resources corresponding to the target entity can be obtained.

[0142] This application does not specifically limit the form in which the virtual resources corresponding to the target entity are obtained. For example, it may involve writing virtual resources to local resource data, writing them to server resource data, updating the quantity of virtual resources, updating user inventory data, or generating the result of obtaining virtual resources.

[0143] The virtual resources corresponding to the target entity can be virtual resources pre-bound to the target entity, or resources determined in real time based on the target entity. For example, a virtual timber entity can correspond to timber resources, a virtual ore entity can correspond to mineral resources, a virtual energy block can correspond to energy resources, a virtual component can correspond to building component resources, a virtual plant can correspond to plant material resources, and a virtual task item can correspond to task progression resources. Furthermore, the target entity itself can also be a virtual resource.

[0144] As can be seen from the above technical solution, when virtual resources need to be acquired, this application can display a first virtual scene interface in resource acquisition mode. The first virtual scene interface includes an initial energy value and entities to be acquired. If the target entity among the entities to be acquired is within the selected range, it means that the target entity can be acquired. When the user wants to acquire the target entity, a acquisition trigger operation can be executed. This application links entity acquisition with the real-time deduction process of energy value. Entity acquisition requires energy value. Therefore, only when the initial energy value is greater than a first energy threshold can there be energy to acquire entities, and only then can the acquisition trigger operation be responded to to perform continuous acquisition of the target entity, playing an animation of continuous acquisition of the target entity. During the playback of the animation of continuous acquisition of the target entity, the initial energy value is deducted as the continuous acquisition progresses to obtain a real-time energy value. When the real-time energy value is greater than the first energy threshold, continuous acquisition continues until the continuous acquisition progress is acquisition complete. When the continuous acquisition progress is acquisition complete, the virtual resource corresponding to the target entity can be acquired, completing the acquisition of the virtual resource. This application links entity acquisition with the real-time deduction of energy values, thereby increasing the sense of urgency and strategic depth in virtual resource acquisition. Simultaneously, this application implements a dynamic constraint mechanism for virtual resource acquisition; that is, continuous entity acquisition requires a certain amount of energy, and as energy is depleted, it becomes difficult to consistently meet the requirements. This avoids unlimited acquisition of virtual resources in a short period, resulting in a more dynamic and immersive experience, reducing the likelihood of user fatigue. Furthermore, because unlimited acquisition of virtual resources is avoided, unlimited data refreshes are prevented, thus reducing computational resource consumption.

[0145] During continuous data acquisition, to enable users to more intuitively perceive changes in real-time energy values, these values ​​can be visualized. The following examples illustrate two display schemes (i.e., two specific implementations of 403).

[0146] Display Scheme 1 uses the visual status of real-time energy values ​​to reflect changes in energy values.

[0147] In one possible implementation, the initial energy value is subtracted as continuous data acquisition progresses to obtain the real-time energy value, and the visual status of the real-time energy value is displayed.

[0148] The visual state is used to visualize the status of the real-time energy value. The real-time energy value can have multiple visual states. Users can intuitively feel the changes in the real-time energy value by switching between different visual states, and they can also perceive the magnitude of the real-time energy value through its visual state.

[0149] The embodiments of this application do not specifically limit the specific display form of the visual state. For example, the visual state can be at least one of the following: graphic state, color state, animation state, text state, and control state.

[0150] For example, visual status can be reflected through color changes in the energy indicator, such as a bright color when the real-time energy value is high and a dark color when the real-time energy value is low. Visual status can also be reflected through icon changes, such as using battery icons, crystal icons, energy core icons, and flame icons to display the real-time energy value. Visual status can also be reflected through animation changes, such as displaying a steady glowing animation when the real-time energy value is high and a flashing red animation when the real-time energy value is low. Visual status can also be reflected through control states, such as the acquisition control corresponding to the acquisition trigger operation displaying different effects under different real-time energy values.

[0151] Specifically, during the playback of the animation showing continuous data acquisition of the target entity, the initial energy value can be deducted as the acquisition progresses to obtain the real-time energy value. Simultaneously, the corresponding visual state can be updated based on the real-time energy value. In other words, when watching the animation of continuous data acquisition of the target entity, users can not only see the acquisition process but also perceive the changes in the current real-time energy value through visual status.

[0152] Therefore, by displaying a real-time visual status of the energy value during the energy deduction process, users can more easily understand the relationship between continuous data collection and energy consumption. Users can also adjust their collection behavior in a timely manner based on the visual status, such as stopping continuous data collection when the visual status indicates that the energy value is low to pause energy deduction, or prioritizing entities that are easier to collect continuously. This avoids continuing to initiate invalid continuous data collection when the energy value is insufficient, thereby improving the strategic nature and controllability of the continuous data collection process.

[0153] In one possible implementation, different visual states can be displayed based on the range of real-time energy values. See A1-A2 for details.

[0154] A1: If the real-time energy value is greater than the first energy threshold and less than the second energy threshold, the visual state displayed when showing the real-time energy value is fatigue state.

[0155] The second energy threshold is used to determine whether the real-time energy value is sufficient; it serves as a state boundary value and can also be called a fatigue threshold. The second energy threshold is greater than the first energy threshold. If the real-time energy value is less than the second energy threshold, it indicates insufficient real-time energy; if the real-time energy value is greater than or equal to the second energy threshold, it indicates relatively sufficient real-time energy. The second energy threshold can be a fixed value or a fixed percentage of the target energy upper limit. For example, if the first energy threshold is 0, the second energy threshold can be 20, or it can be 20% of the target energy upper limit. The target energy upper limit indicates the upper limit of the energy value.

[0156] As one implementation method, the second energy threshold can also be dynamically determined based on at least one of the following: the difficulty of collecting the target entity, the resource acquisition mode, the user level, and the rarity of the target entity. For example, the higher the difficulty of collecting the target entity, the higher the second energy threshold, so as to alert the user earlier that the current energy value is low.

[0157] The fatigue state indicates that the real-time energy value is low. In the fatigue state, although the real-time energy value is still greater than the first energy threshold, allowing continuous data acquisition to continue, the real-time energy value has fallen below the second energy threshold, indicating that the real-time energy value is approaching a point where it can no longer support continuous data acquisition. Users can perceive the low real-time energy value through the fatigue state. If continuous data acquisition continues, it may be paused due to insufficient energy before the target entity reaches the completion point.

[0158] This application does not specifically limit the specific display form of the fatigue state. For example, the fatigue state can be reflected by darkening the color of the energy value, flashing the icon, shaking the screen, displaying a prompt light effect at the edge of the interface, or displaying a text prompt that the remaining energy is low.

[0159] Specifically, during continuous data acquisition, if the real-time energy value is greater than the first energy threshold, it indicates that the energy conditions for continuing continuous data acquisition are still met. If the real-time energy value is further lower than the second energy threshold, it indicates that the real-time energy value is low. At this time, the terminal can visually display the real-time energy value as a fatigue state to remind the user that although the continuous data acquisition has not stopped, the energy value may not be sufficient to support subsequent continuous data acquisition for an extended period.

[0160] See Figure 5 The figure is a schematic diagram illustrating a real-time energy value in a fatigue state according to this application. Figure 5 As shown, taking a first energy threshold of 0 and a second energy threshold of 30 as an example, if the real-time energy value is 20, the visual state displayed for the real-time energy value is a fatigue state, which can be represented by filling the part of the real-time energy value with gray color and bar patterns. Furthermore, the "fatigue state" can be displayed near the location where the real-time energy value is displayed.

[0161] A2: If the real-time energy value is greater than or equal to the second energy threshold, the visual state of the real-time energy value is displayed as normal.

[0162] The normal state indicates that the real-time energy value is relatively sufficient. Under the normal state, the real-time energy value is not only greater than the first energy threshold, but also greater than or equal to the second energy threshold, thus enabling relatively stable support for the continued execution of the continuous acquisition process.

[0163] This application does not specifically limit the display format of the normal state in its embodiments. For example, the normal state can be represented by a constantly lit energy value, a stable progress display, or controls of normal color. It can also be indicated by text prompts, such as "Sufficient energy" or "Continuous data collection."

[0164] Specifically, during continuous data acquisition, if the real-time energy value is greater than or equal to the second energy threshold, it indicates that the real-time energy value is relatively sufficient, and the terminal can display the visual status of the real-time energy value as normal. By switching between the normal state and the fatigue state, users can intuitively see the change in the real-time energy value from sufficient to low during continuous data acquisition.

[0165] See Figure 6 The figure is a schematic diagram illustrating a real-time energy value in a normal state according to this application. Figure 5 As shown, taking a first energy threshold of 0 and a second energy threshold of 30 as an example, if the real-time energy value is 70, then the visual state of displaying the real-time energy value is normal, and the part representing the real-time energy value can be filled with gray. Furthermore, "normal state" can be displayed near the location where the real-time energy value is displayed.

[0166] Therefore, by setting a first energy threshold and a second energy threshold, real-time energy values ​​can be divided into different state ranges and displayed differently based on normal and fatigue states. This not only indicates whether the energy value is sufficient but also provides early feedback before the energy value is about to run out, allowing users to determine in advance whether to continue continuous data collection on the current target entity, thereby improving the strategic nature and predictability of the continuous data collection process.

[0167] Furthermore, if the real-time energy value drops to a level that can no longer support continuous data acquisition, a lockout state can be displayed, and continuous data acquisition can resume once the energy value recovers. See B1-B3 for details.

[0168] B1: If the real-time energy value is less than or equal to the first energy threshold, the visual status of the real-time energy value is locked, and continuous acquisition is paused, while the progress of continuous acquisition at the current moment is retained.

[0169] In this embodiment, the locked state indicates that the real-time energy value no longer meets the energy conditions for continuing continuous data acquisition. When the visual state of the real-time energy value is locked, data acquisition of the target entity is impossible.

[0170] It should be noted that the locked state can be the visual state corresponding to the real-time energy value or the display state corresponding to the crosshair indicator. This will be explained in detail later through C1-C3, and will not be repeated here.

[0171] This application does not specifically limit the specific display form of the locked state. For example, the locked state may be manifested as the space turning gray, displaying a lock icon, displaying a low energy prompt on the interface, or pausing animation.

[0172] Specifically, during continuous data acquisition, the terminal continuously determines whether the conditions for continuing continuous data acquisition are met based on the real-time energy value. If the real-time energy value is less than or equal to the first energy threshold, it indicates that the current energy value is insufficient to continue supporting continuous data acquisition. At this time, the terminal displays a locked state and pauses continuous data acquisition, while retaining the progress of continuous data acquisition at the current moment.

[0173] Pausing continuous data acquisition means that when the real-time energy value does not meet the conditions for continuing execution (such as being less than or equal to the first energy threshold), the terminal stops advancing the continuous data acquisition progress. The current moment is the moment when continuous data acquisition is paused. By preserving the progress of continuous data acquisition at the current moment, execution can be continued based on the completed progress when continuous data acquisition is resumed, instead of starting from the initial progress.

[0174] For example, if the first energy threshold is 0, and the continuous acquisition progress has reached 60%, but the real-time energy value drops to 0, the terminal can pause the continuous acquisition and retain 60% of the continuous acquisition progress.

[0175] See Figure 7 The figure is a schematic diagram illustrating a real-time energy value in a locked state according to this application. Figure 7 As shown, taking a first energy threshold of 0 as an example, if the real-time energy value is 0, the visual state displaying the real-time energy value is locked. This can be achieved through... Figure 7 The lock icon next to the energy value indicates a locked state. Furthermore, a "locked state" display could be shown near the location where the real-time energy value is displayed.

[0176] B2: Restores energy value to real-time energy value.

[0177] The process of restoring energy value to an increased energy value.

[0178] Specifically, after continuous data collection is paused, the terminal can restore the real-time energy value, causing the real-time energy value to continuously increase.

[0179] This application does not specifically limit the method of energy value restoration. Energy value restoration can be performed automatically according to preset restoration rules, in response to a user-executed restoration operation, or triggered based on restoration conditions in the scenario. The following describes three restoration methods:

[0180] Recovery Method 1: Automatic recovery based on time, for example, a certain amount of energy is restored after a preset recovery time.

[0181] The energy recovery method described above can be expressed by the following formula:

[0182]

[0183] in, The energy value recovered after each frame time interval. The rate of energy recovery. Let be the frame time interval. The energy value after each update can be expressed by the following formula:

[0184] in, This represents the energy value after each update. The current energy value, The energy value recovered after each frame time interval. This represents the upper limit of the target energy.

[0185] The second recovery method restores energy values ​​in response to a user-executed recovery action. For example, the recovery action could be triggered by the user actively clicking a control, or it could be automatically triggered after the user pauses data collection.

[0186] The third recovery method restores energy after meeting certain conditions. For example, recovery conditions could include picking up energy items, entering a recovery area, triggering a recovery skill, or completing a stage task, all of which increase energy levels.

[0187] B3: When the real-time energy value recovers to a level greater than the first energy threshold, the real-time energy value lock is released, and continuous acquisition resumes on the basis of the retained continuous acquisition progress.

[0188] The unlocked state means that after the real-time energy value meets the energy conditions for continuous acquisition again (such as recovering to a value greater than the first energy threshold), the real-time energy value will no longer be displayed as locked, and continuous acquisition can continue.

[0189] Specifically, during the energy value recovery process, the terminal can synchronously update the visual status of the real-time energy value. When the real-time energy value recovers to a level greater than the first energy threshold, it indicates that the current energy value once again meets the conditions for continuing continuous data acquisition. At this point, the terminal can unlock the real-time energy value and resume continuous data acquisition based on the previously retained progress. In other words, the continuous data acquisition process will not completely fail due to a single energy deficiency, but can continue to advance the original progress after the energy value recovers.

[0190] For example, if the target entity has completed 60% of the progress before pausing continuous acquisition, continuous acquisition can continue from 60% progress once the real-time energy value recovers to a level greater than the first energy threshold.

[0191] Therefore, by displaying a locked state, pausing continuous data acquisition, and retaining the progress of continuous data acquisition when the real-time energy value is less than or equal to the first energy threshold, users can intuitively see that continuous data acquisition is paused due to insufficient energy, thereby further increasing the sense of urgency in acquiring virtual resources. At the same time, after the energy value recovers, continuous data acquisition can continue based on the retained progress, which can avoid users repeating the acquisition steps due to temporary energy shortage, reduce the number of animation playbacks and progress calculations, and thus reduce the terminal's computing resource consumption.

[0192] Based on the above embodiments, by combining a limited total energy value design, an energy value deduction mechanism, and an energy value recovery rate, a virtual resource acquisition rhythm control process of consumption, waiting, recovery, and re-consumption can be constructed. The energy value range corresponding to the fatigue state can provide users with a warning signal that their energy value is about to run out, and the triggering of the lock state can force a cooling-off interval in the virtual resource acquisition process when the energy value is insufficient. Thus, the virtual resource acquisition rhythm can naturally form a wave-like experience curve of efficient collection period, fatigue warning period, lock-off cooling period, and recovery restart period, avoiding experience fatigue caused by continuous unlimited collection, while giving users strategic decision-making space for when to collect, how much to collect, and whether to continue collecting.

[0193] Option 2 displays the energy value change through an energy progress bar.

[0194] In one possible implementation, the initial energy value can be represented by an energy progress bar, where the outline of the progress bar represents the target energy upper limit, and the fill length of the energy progress bar represents the initial energy value.

[0195] The energy progress bar is a bar indicator used to visualize the current status of the energy value. For example, the energy progress bar can be a horizontal bar, a vertical bar, a circular bar, a semi-circular bar, etc.

[0196] The progress bar's outer frame indicates the maximum achievable energy value range, while the fill length indicates the current energy value, such as the initial energy value or the real-time energy value. The target energy limit can be preset or dynamically determined based on user level, resource acquisition mode, gathering tools, task status, etc.

[0197] In this scenario, the method for obtaining the real-time energy value by deducting the initial energy value as continuous data collection progresses can be achieved by shortening the fill length of the energy progress bar as continuous data collection progresses. This real-time fill length represents the real-time energy value. In other words, during continuous data collection, the initial energy value can be deducted as continuous data collection progresses, and the fill length of the energy progress bar can be shortened accordingly to obtain the real-time fill length. Users can intuitively perceive the energy consumption during continuous data collection by using the real-time fill length.

[0198] The real-time fill length is the fill length obtained by shortening the initial energy value in real time during continuous data acquisition, and is used to represent the real-time energy value. As continuous data acquisition progresses, the initial energy value is gradually deducted, and the fill length of the energy progress bar is shortened accordingly.

[0199] See Figure 8 This figure is a schematic diagram of an energy progress bar provided in an embodiment of this application. Figure 8 As shown, the fill length of the energy progress bar can be used to represent the real-time energy value, such as 70, and the outer frame of the energy progress bar is used to represent the upper limit range that the energy value can reach, such as 100.

[0200] Therefore, by using the outline of the energy progress bar to represent the target energy limit and the fill length to represent the current energy value, both the energy limit and remaining energy can be displayed to the user simultaneously. Furthermore, as the energy value decreases and the fill length shortens during continuous data collection, the progress of continuous data collection and energy consumption are presented more visually, enhancing the user's perception of the continuous data collection process. The energy progress bar allows users to quickly determine whether the current energy value is sufficient to continue continuous data collection, reducing the number of times users attempt invalid continuous data collection operations.

[0201] In one possible implementation, the energy progress bar may include a native segment progress bar and an extended segment progress bar. The target energy limit value includes a native energy limit value and an extended energy limit value. The outline of the native segment progress bar represents the native energy limit value, and the outline of the extended segment progress bar represents the extended energy limit value.

[0202] The native energy cap represents the basic upper limit of energy that can be achieved without an increase in the energy cap. The extended energy cap represents the additional energy cap beyond the native energy cap. The target energy cap can be determined jointly by the native energy cap and the extended energy cap. For example, if the native energy cap is 100 and the extended energy cap is 20, then the target energy cap can be 120.

[0203] The native segment progress bar represents the maximum original energy value, while the extended segment progress bar represents the maximum extended energy value. The native and extended segment progress bars can be set continuously or in segments.

[0204] This application does not specifically limit the display style of the original progress bar and the added progress bar. The original progress bar and the added progress bar can use the same display style, or they can be distinguished by different borders, textures, transparency, strokes, etc.

[0205] For example, the native energy cap can be the default energy cap a user has when entering resource acquisition mode, while the extended energy cap can be the additional energy cap a user gains by fulfilling certain conditions for increasing the cap. Conditions for increasing the cap may include at least one of the following: obtaining energy-boosting items, completing a specified task, triggering a resource acquisition bonus state, increasing the user's level, or entering a specific area.

[0206] Specifically, during continuous data collection, the outline of the original segment progress bar can be displayed based on the original energy limit, and the outline of the extended segment progress bar can be displayed based on the extended energy limit. If the real-time energy value is deducted as the continuous data collection progresses, the fill length in the original segment progress bar can be updated accordingly and / or the fill length in the segment progress bar can be increased, so that the energy consumption process after the energy limit is increased can be synchronously reflected in the energy progress bar.

[0207] See Figure 9 This figure is one of the schematic diagrams of a native segment progress bar and an added segment progress bar provided in an embodiment of this application. Figure 9 As shown, the energy progress bar can include a primary progress bar at the beginning and an additional progress bar following the primary progress bar. If the real-time energy value does not exceed the primary energy limit, the filled portion of the energy progress bar can be displayed within the primary progress bar.

[0208] See Figure 10 This figure is a second schematic diagram of a native segment progress bar and an added segment progress bar provided in an embodiment of this application. Figure 10 As shown, if the real-time energy value exceeds the original energy limit, the filling part of the energy progress bar can be further extended into the additional segment progress bar.

[0209] In one possible implementation, in response to displaying the progress bar for increasing the segment, a prompt message indicating the expanded energy limit value can also be displayed, such as "Limit increased by 60".

[0210] Therefore, by dividing the energy progress bar into a native segment and an incremental segment, and displaying the expanded energy limit value through the incremental segment, the energy progress bar can support the display of the limit increase. After the user meets the limit increase conditions, the continuous collection process can obtain more consumable energy, thereby improving the user's ability to perform continuous collection.

[0211] Meanwhile, adding a progress bar directly displays the effect of the increased energy cap in the first virtual scene interface, allowing users to intuitively see the result of the expanded energy cap. This enables users to perceive the effect of the increased energy cap, thereby encouraging them to actively meet the conditions for the cap increase and enriching the gameplay and strategic choices surrounding the acquisition of virtual resources.

[0212] This application does not specifically limit how to determine that a target entity in the entity to be acquired is within a selected range. For example, it can be determined based on the distance between the target entity and the virtual character. If the distance between the target entity and the virtual character is less than a selected distance threshold, then the target entity is determined to be within the selected range. Similarly, if the angular difference between the target entity and the virtual camera's orientation is less than a selected angle threshold, then the target entity is determined to be within the selected range.

[0213] In one possible implementation, in order to enable the user to accurately identify the target entity from multiple entities to be acquired in the first virtual scene interface, a crosshair indicator can be displayed in the first virtual scene interface, and the crosshair indicator can be used to determine whether the target entity among the entities to be acquired is within the selected range.

[0214] The crosshair indicator is a visual aiming marker displayed in the first virtual scene interface, used to indicate the user's current selected range.

[0215] In one implementation, the crosshair indicator can be a fixed interface element displayed in the first virtual scene interface, such as in the center of the first virtual scene interface, or it can be an interface element that can move with user operation, changes in viewing angle, and changes in the direction of the input device. The crosshair indicator can be used to assist the user in aiming, selecting, locking, or snapping to select entities to be acquired.

[0216] Specifically, if the crosshair indicator hits the target entity, the target entity is within the selected range.

[0217] See Figure 11 This figure is a schematic diagram of a crosshair indicator provided in an embodiment of this application. Figure 11As shown, the crosshair indicator can be displayed in the center area of ​​the first virtual scene interface to indicate the currently selected area by the user. The crosshair indicator can be represented by multiple line segments spaced at intervals, such as four line segments forming a cross or near-cross-shaped indicator area. Users can adjust the virtual camera orientation, move the viewing angle, drag the screen, move the mouse, operate the joystick, etc., to make the selected area corresponding to the crosshair indicator hit the target entity.

[0218] As one implementation method, it is possible to determine whether a target entity has been hit by judging whether the crosshair indicator meets preset hit conditions. This application does not specifically limit the preset hit conditions; the following five preset hit conditions are provided as examples:

[0219] The first preset hit condition is that the center point of the crosshair indicator is located within the display area corresponding to the target entity. For example, if the crosshair indicator is a circular selected area, the terminal can determine whether the entity to be acquired falls within the circular selected area. If it does, it is determined that the crosshair indicator has hit the entity to be acquired.

[0220] The second preset hit condition is that the ray emitted from the crosshair indicator intersects with the collision area corresponding to the target entity, i.e., ray detection. For example, if the crosshair indicator is a crosshair located in the center of the first virtual scene interface, the terminal (or server) can generate a selected ray based on the orientation of the virtual camera and determine whether the selected ray intersects with the collision area corresponding to the entity to be acquired. If they intersect, it is determined that the crosshair indicator has hit the entity to be acquired, and the entity to be acquired is taken as the target entity.

[0221] Preset hit condition three: the distance between the selected range corresponding to the crosshair indicator and the target entity is less than the hit distance threshold.

[0222] Preset hit condition four: the angle difference between the selected range corresponding to the crosshair indicator and the target entity is less than the hit angle threshold.

[0223] Preset hit condition five: the overlapping area between the selected range corresponding to the crosshair indicator and the target entity is less than the hit area threshold.

[0224] Therefore, by setting a crosshair indicator in the first virtual scene interface, when the crosshair indicator hits the target entity, it is determined that the target entity is within the selected range, thereby corresponding the user's visual perception with the selection result of the target entity, reducing the situation where the user mistakenly selects other entities to be acquired, and improving the accuracy of selecting the target entity.

[0225] This application does not specifically limit the display of the crosshair indicator's state. Several display methods for different states are described below as examples.

[0226] Status display mode 1: Switches from unaimed to aimed.

[0227] In one possible implementation, after the crosshair indicator hits the target entity, the state of the crosshair indicator can be further switched to indicate to the user that the target entity has been selected. Specifically, after the target entity is within the selected range if the crosshair indicator hits the target entity, the crosshair indicator can be switched from an unaimed state to an aimed state.

[0228] The "Unaimed" state indicates that the crosshair indicator has not yet hit an entity that can be continuously acquired. The "Aimed" state indicates that the crosshair indicator has hit the target entity, and the target entity is within the selected range. The user can then trigger an acquisition operation to begin continuous acquisition of the target entity if the energy value condition is met (e.g., the real-time energy value is greater than a first energy threshold). The Unaimed and Aimed states can be distinguished by different display methods, such as display appearance, display color, display size, display animation, display transparency, and display prompts.

[0229] For example, in the unaimed state, the crosshair indicator can be displayed as a crosshair of a normal color; in the aimed state, the crosshair indicator can be switched to a highlighted color and rotated by a preset angle.

[0230] For example, in the unaimed state, nothing is displayed near the crosshair indicator; in the aimed state, the name of the target entity, acquisition prompts, and other detailed information can be displayed near the crosshair indicator.

[0231] See Figure 12 This figure is a schematic diagram of a crosshair indicator in an unaimed state according to an embodiment of this application. Figure 12 As shown, when the crosshair indicator misses the target entity, it can be viewed from... Figure 11 The aiming state shown is switched to the unaimed state by rotating the icon corresponding to the crosshair indicator, so that the user can clearly see that no entity has been hit.

[0232] Therefore, by switching the crosshair indicator from an unaimed state to an aimed state after it hits the target entity, the hit judgment result in the background is transformed into a user-perceptible interface feedback. Users can intuitively confirm that the target entity has been selected, thereby reducing repetitive operations caused by uncertainty about whether the target entity has been hit, such as aiming operations for the crosshair indicator and acquisition trigger operations, reducing the number of operations and thus reducing the consumption of computing resources.

[0233] Status display method two: Data collection in progress.

[0234] In one possible implementation, in response to a data acquisition trigger operation, the crosshair indicator is displayed as being in the data acquisition state, and an animation of continuous data acquisition of the target entity is played.

[0235] The "Data Acquisition in Progress" status indicates that continuous data acquisition is in progress and has not yet been completed. Furthermore, the "Data Acquisition in Progress" status can also be used to reflect the progress of continuous data acquisition.

[0236] See Figure 13 This figure is a schematic diagram of a crosshair indicator in the acquisition process, provided in an embodiment of this application. Figure 13 As shown, the crosshair indicator can display a circular progress bar while acquisition is in progress. The filled portion of the circular progress bar is used to indicate the progress of continuous acquisition.

[0237] For example, the crosshair indicator can be displayed as a gradually shrinking aperture around the target entity, the degree of shrinkage of the aperture being used to indicate the progress of continuous acquisition.

[0238] Therefore, by displaying the acquisition status and continuous acquisition progress through the crosshair indicator, the acquisition status and progress can be centralized into a single interface element. Users no longer need to repeatedly switch their gaze between multiple interface elements to understand that the current target entity has been selected and continuous acquisition is in progress, thus reducing the operational and observational costs required for users to obtain interface information. Furthermore, since the crosshair indicator itself is used for target selection, further displaying the continuous acquisition progress on it reduces the need for additional independent progress controls, decreases the number of interface elements and interface refresh complexity, thereby reducing the rendering overhead on the terminal.

[0239] The third status display method switches between the acquisition status and the locked status.

[0240] In one possible implementation, the crosshair indicator can switch between a data acquisition in progress state and a locked state. See C1-C3 for details.

[0241] C1: If the real-time energy value is less than or equal to the first energy threshold, pause continuous acquisition and switch the status displayed on the crosshair indicator from acquisition in progress to locked state.

[0242] The locked state indicates that the real-time energy value is less than or equal to the first energy threshold, and continuous data acquisition is paused due to insufficient energy. In other words, the locked state indicates that continuous data acquisition cannot continue temporarily.

[0243] For example, when acquisition is in progress, the crosshair indicator can be displayed as a ring-shaped progress bar that is filling; when locked, the ring-shaped progress bar can stop filling and switch to a gray state.

[0244] See Figure 14 This figure is a schematic diagram of a crosshair indicator in a locked state according to an embodiment of this application. Figure 14 As shown, taking a first energy threshold of 0 as an example, if the real-time energy value is 0, it can be achieved through methods such as... Figure 12 The icon for the unaimed state shows the crosshair indicator to indicate that the crosshair indicator is locked.

[0245] C2: Restores energy value to real-time energy value.

[0246] For relevant details, please refer to B2; further details will not be provided here.

[0247] C3: When the real-time energy value recovers to a level greater than the first energy threshold, the state displayed on the crosshair indicator will be switched from the locked state to the acquisition in progress state.

[0248] Specifically, when the real-time energy value recovers to a level greater than the first energy threshold, it indicates that the real-time energy value once again meets the energy conditions for continuing continuous data acquisition. At this time, the terminal can switch the state displayed on the crosshair indicator from the locked state to the acquisition in progress state, and continue playing the animation of continuous data acquisition of the target entity.

[0249] For example, if the crosshair indicator displays a gray circular progress bar in the locked state, it can revert to a bright circular progress bar when the real-time energy value recovers to above the first energy threshold, and continue displaying the progress of continuous acquisition. Alternatively, if the crosshair indicator displays a lock icon in the locked state, the lock icon can disappear when the real-time energy value recovers, and the crosshair indicator can redisplay the effect corresponding to the acquisition progress status.

[0250] Therefore, when continuous data acquisition is paused due to insufficient real-time energy, switching the crosshair indicator from the acquisition in progress state to the locked state allows the user to intuitively understand that acquisition cannot continue due to insufficient energy. Once the real-time energy recovers, switching the crosshair indicator back from the locked state to the acquisition in progress state clearly allows the user to understand that continuous acquisition can resume. By switching the display state of the crosshair indicator, the locking and resuming of continuous acquisition can be clearly understood by the user through a single interface element, reducing the number of times the user repeatedly triggers acquisition operations due to a lack of understanding of the locking reason, thereby reducing the number of times the terminal responds to invalid operations.

[0251] The fourth status display mode is to switch between the acquisition in progress status and the aimed status.

[0252] In one possible implementation, during continuous data acquisition—that is, while the crosshair indicator is in the acquisition process—the user can actively pause continuous acquisition and resume it when the acquisition trigger operation is re-executed. See D1-D2 for details.

[0253] D1: If continuous acquisition is paused in response to an acquisition pause operation, the crosshair indicator will switch from the acquisition in progress state to the aiming state.

[0254] The "Pause Data Collection" option refers to the user's action of voluntarily pausing continuous data collection.

[0255] Specifically, if the terminal receives a pause operation when the crosshair indicator shows "Acquisition in Progress" and continuous acquisition is in progress, it can pause the continuous acquisition and switch the crosshair indicator from "Acquisition in Progress" to "Aimed." At this time, the target entity remains within the selected range; only the continuous acquisition process has been actively paused by the user. In other words, after the crosshair indicator switches from "Acquisition in Progress" to "Aimed," it stops displaying the progress of continuous acquisition but continues to show the target entity being hit by the crosshair indicator.

[0256] As an implementation method, the operation methods of data collection triggering and data collection pausing are related.

[0257] For example, if the data acquisition trigger operation is a long press, the data acquisition pause operation can be the user releasing the press. If the data acquisition trigger operation is a click on the data acquisition control, the data acquisition pause operation can be the user clicking the data acquisition control again, or clicking the pause control. If the data acquisition trigger operation is a controller trigger press, the data acquisition pause operation can be releasing the controller trigger.

[0258] D2: When the acquisition trigger operation is executed again, the animation of continuous acquisition of the target entity continues to play, and the state displayed by the crosshair indicator is switched from the aiming state to the acquisition in progress state.

[0259] Taking the user releasing the acquisition control as a pause operation, when the user presses and holds the acquisition control again, the terminal can continue playing the animation of continuously acquiring data from the target entity and redisplay the crosshair indicator as in acquisition mode.

[0260] As a result, users can actively pause continuous acquisition, making the acquisition process more controllable and flexible. Furthermore, by switching the crosshair indicator between the acquisition in progress state and the aimed state, users can clearly understand the locking and resuming of continuous acquisition through a single interface element. This reduces the number of times users repeatedly trigger acquisition operations due to not understanding the locking reason, thereby reducing the number of times the terminal responds to invalid operations.

[0261] The fifth status display method is a locked state with accompanying prompts.

[0262] In one possible implementation, if the user still performs the acquisition trigger operation when the crosshair indicator has hit the target entity but the initial energy value is insufficient, the first prompt message can be displayed and the crosshair indicator can be displayed as locked.

[0263] Specifically, if the target entity is within the selected range and the initial energy value is less than or equal to the first energy threshold, in response to the acquisition trigger operation, the first prompt message is displayed and the crosshair indicator is displayed as locked.

[0264] The first prompt message indicates that the initial energy value is insufficient. For example, the first prompt message can be a text prompt, an icon prompt, an animated prompt, or a combination of the above prompt methods.

[0265] For example, the first prompt message may display text such as "Insufficient energy," "Current energy value is insufficient," "Please wait for energy to recover," or "Unable to start data acquisition." The crosshair indicator may display a grayed-out state, a locked state, a disabled state, a flashing warning state, or other states indicating that continuous data acquisition cannot be started.

[0266] See Figure 15 This figure is a schematic diagram of displaying a first prompt message provided in an embodiment of this application. The user can execute a data collection trigger operation by clicking the data collection control. For example, the data collection control is grayed out to indicate that the user is clicking it, and the first energy threshold is 0. Figure 15 As shown, the initial energy value is 0. Even if the user clicks, the crosshair indicator will switch to the state shown. Figure 14 The system is in a locked state and displays the first message: "Insufficient energy, please wait for energy to recover."

[0267] Therefore, by displaying the first prompt message when the target entity is within the selected range but the initial energy value is insufficient, and displaying the crosshair indicator as locked, the user can be clearly instructed not to execute before continuous acquisition is started, thereby limiting invalid continuous acquisition processes. This can reduce the number of acquisition trigger operations, the number of animation playbacks and invalid data requests, and reduce the consumption of computing and rendering resources.

[0268] Based on the above embodiments, by dynamically linking the acquisition trigger operation with the real-time energy deduction process, and combining the visual feedback switching of the crosshair indicator between the unaimed state, the aimed state, the acquisition in progress state, and the locked state, as well as the display changes of the energy progress bar between the normal state, the fatigue state, and the locked state, a multi-dimensional dynamic mapping relationship between the user's operation process and the state of the virtual resource acquisition device can be established. When performing continuous acquisition, the user can perceive the changes in energy consumption, the state transition of the crosshair indicator, and the staged warnings of the energy progress bar in real time. For example, the user can know that the energy is about to run out through the display changes of the fatigue state. This improves the virtual resource acquisition experience from a single trigger result mode to a multi-layered immersive interactive experience of discovering target entities, aiming at target entities, continuous acquisition, perceiving energy deduction, and making strategic decisions, thereby increasing the dimensions of operation feedback and the richness of the interaction process.

[0269] During continuous data acquisition, users can actively pause the acquisition process using the pause operation. To avoid requiring users to restart continuous acquisition of the target entity after each pause, this application proposes a specific implementation method for interruption recovery, as detailed in E1-E3.

[0270] E1: During the playback of the animation of continuous acquisition of the target entity, in response to the acquisition pause operation, the continuous acquisition is paused, while the real-time energy value and the progress of continuous acquisition at the current moment are retained.

[0271] The real-time energy value at the current moment is the initial energy value after deducting from the continuous acquisition progress when the acquisition pause operation is received. The continuous acquisition progress at the current moment is the progress of continuous acquisition completed by the target entity when the acquisition pause operation is received.

[0272] Specifically, during the playback of the animation of continuous data acquisition of the target entity, the terminal can continuously update the real-time energy value and the progress of continuous acquisition. If the terminal receives a data acquisition pause operation, it can stop advancing the continuous acquisition progress and record the real-time energy value and the current continuous acquisition progress. For example, if the continuous acquisition progress of the target entity has progressed to 45% and the real-time energy value has decreased from 60 to 35, and the user releases the acquisition button, the terminal can pause the continuous acquisition and record the real-time energy value of 35 and the continuous acquisition progress of 45%.

[0273] This application does not specifically limit the scope of the continuous acquisition progress retention. As one implementation, the continuous acquisition progress can be the progress retained within the current resource acquisition mode. That is, if the user pauses continuous acquisition and then re-executes the acquisition trigger operation without exiting the resource acquisition mode, the terminal can continue continuous acquisition based on the retained progress. If the user exits the resource acquisition mode, or the first virtual scene interface is closed, the retained continuous acquisition progress can be cleared. When the user re-enters the resource acquisition mode, continuous acquisition of the target entity needs to be performed again.

[0274] As another implementation method, the progress of continuous acquisition can also be globally retained. That is, even if the user exits the resource acquisition mode, the terminal can save the progress of continuous acquisition corresponding to the target entity. When the user re-enters the resource acquisition mode and selects the target entity, continuous acquisition can continue based on the previously saved progress.

[0275] E2: During the pause of continuous data collection, restore the energy value based on the real-time energy value at the current moment.

[0276] Specifically, after continuous data acquisition is paused, the terminal can stop deducting real-time energy and restore the energy value based on the real-time energy value at the time of the pause. In other words, the energy value after the pause is not recalculated from the initial energy value, but rather increased based on the remaining real-time energy value at the current moment. For example, if the current real-time energy value is 35, and the energy value recovers at a rate of 5 points per second, then after a 2-second pause, the energy value can recover to 45.

[0277] The embodiments in this application do not specifically limit the method of energy value recovery. For relevant details, please refer to B2 above, which will not be repeated here.

[0278] E3: When the acquisition trigger operation is re-executed, continue playing the animation of continuous acquisition of the target entity, use the real-time energy value after the energy value increases as the initial energy value, and continue to execute S403.

[0279] Specifically, after the user re-executes the data collection trigger operation, the terminal can continue playing the animation of continuous data collection on the target entity based on the previously retained continuous data collection progress. Simultaneously, the terminal can use the real-time energy value restored during the pause as the new initial energy value, and continue to subtract this initial energy value from the real-time energy value as the continuous data collection progresses. As long as the real-time energy value exceeds a first energy threshold, continuous data collection continues until the continuous data collection progress reaches the completion stage.

[0280] For example, if the continuous acquisition progress of the target entity is 45% when paused, and the real-time energy value recovers from 35 to 45 during the pause, then when the user presses and holds the acquisition button again, the terminal can continue playing the animation from the 45% continuous acquisition progress and continue to deduct energy with 45 as the new initial energy value.

[0281] Therefore, by preserving real-time energy values ​​and the progress of continuous data acquisition when a pause operation is triggered, and restoring energy values ​​based on the preserved real-time energy values ​​during the pause, the continuous data acquisition process can support user-initiated interruption and subsequent resumption. Users can not only stop energy deduction by pausing continuous data acquisition and wait for energy values ​​to recover before continuing continuous data acquisition of the target entity, thus improving the controllability of the continuous data acquisition process, but also, since resumption can be based on the preserved progress of continuous data acquisition, users do not need to re-complete the already executed continuous data acquisition portions, reducing redundant operations and waiting times. This minimizes the need to restart continuous data acquisition from the beginning after a pause, thereby reducing computational resource consumption.

[0282] Based on the above embodiments, a release-and-unhook mechanism triggered by a pause operation enables flexible interruption and resume of continuous data acquisition. Specifically, when continuous acquisition is interrupted, the consumed energy value is not refunded, thereby enhancing the user's sense of the importance of acquisition timing and duration. Simultaneously, the completed continuous acquisition progress for the target entity is retained, preventing the user from having to start acquisition from scratch due to release, misoperation, or temporary pause. The user can subsequently re-execute the acquisition trigger operation and continue continuous acquisition of the same target entity from the retained acquisition progress. Furthermore, combined with the gradual display change of the energy progress bar from normal state to fatigue state to locked state, and the energy value recovery process, a gradual state awareness chain can be provided to the user from normal operation to cautious operation to waiting for recovery. Compared to interruption-to-zero or uninterruptible methods, this application significantly improves the fault tolerance and strategy flexibility of the continuous acquisition process.

[0283] This application does not specifically limit the display method for the target entity. The following describes two display methods as examples.

[0284] The first method for displaying target entities is to display entity information with high rarity.

[0285] In one possible implementation, after the target entity is within the selected range, it can be determined whether to display the entity information of the target entity based on the rarity of the target entity.

[0286] Rarity represents the scarcity level of a target entity. A rarity threshold is used to determine whether a target entity requires special mention. The rarity threshold can be a fixed threshold or dynamically determined based on factors such as resource acquisition patterns and user level.

[0287] Entity information is used to describe relevant information about an entity. This application does not specifically limit the content of the entity information. For example, entity information may include the entity's name, icon, type, rarity, quality level, brief description, purpose, available resources, collection difficulty, required energy value, remaining collectable amount, task-related prompts, etc.

[0288] Specifically, after the terminal determines that the target entity among the entities to be acquired is within the selected range, it can obtain the rarity of the target entity and determine whether the rarity of the target entity is higher than the rarity threshold. If the rarity of the target entity is higher than the rarity threshold, it means that the target entity has a higher prompting value than ordinary target entities, and the terminal can display the entity information of the target entity in the first virtual scene interface. If the rarity of the target entity is not higher than the rarity threshold, the terminal may not display the entity information of the target entity.

[0289] For example, if the target entity is a common entity such as ordinary wood or ordinary stone, and its rarity is not higher than the rarity threshold, the terminal can simply display that the target entity has been selected without displaying any additional entity information. If the target entity is a rare ore, a limited-use quest item, or the like, and its rarity is higher than the rarity threshold, the terminal can display the entity information corresponding to that target entity.

[0290] See Figure 16 This figure is a schematic diagram illustrating the display of entity information provided in an embodiment of this application. For example... Figure 16 As shown, taking a leaf with a rarity higher than the rarity threshold as an example, after the target entity is within the selected range, the entity information of the target entity can be displayed, including the entity name, collection difficulty and purpose, such as "Epic Leaf, Collection Difficulty: High, Used to decorate houses".

[0291] This application provides differentiated visual feedback for target entities of varying rarity. By displaying entity information only when the entity's rarity exceeds a threshold, more comprehensive and intuitive information can be provided to users for data collection decisions, especially when the target entity has high cue value. When faced with a high-rarity target entity, users can learn about its relevant information before performing continuous data collection, thus reducing the probability of missing high-value entities. For entities with lower rarity, unnecessary information display can be reduced, preventing the first virtual scene interface from being overwhelmed by a large amount of entity information and further reducing the consumption of display resources.

[0292] The second way to display the target entity is to display the entity information corresponding to the quality level.

[0293] In one possible implementation, when displaying the entity information of the target entity, the entity information of the target entity can also be displayed with a display appearance corresponding to the quality level of the target entity.

[0294] The quality grade is used to represent the quality difference of a target entity among entities of the same type. The quality grade can be related to the target entity's resource value, acquisition difficulty, and exchangeable value. The quality grade can be represented by different level identifiers, such as Common, Excellent, Rare, Epic, and Legendary, or by other methods such as numbers and colors.

[0295] Display appearance refers to the appearance adopted by entity information in the first virtual scene interface. This application embodiment does not specifically limit the specific form of the display appearance. Display appearance may include border style, font color, icon style, transparency, display size, etc.

[0296] Specifically, when the terminal determines that entity information of the target entity needs to be displayed, it can further obtain the quality level of the target entity and determine the corresponding display appearance based on the quality level. Different quality levels can correspond to different display appearances, allowing users to not only read the content of entity information when they see it, but also quickly determine the quality level of the target entity through the display appearance.

[0297] As one implementation method, the higher the quality level, the more prominent the displayed entity information becomes. For example, a target entity of ordinary quality can display its information using a plain border and plain font, while a target entity of higher quality can display its information using a highlighted border and a special colored font. Furthermore, different quality levels can be represented by different background colors such as white, green, blue, purple, orange, and red.

[0298] For example, you can display entity information by hovering over the information bubble. When the crosshair indicator hits a high-rarity target, a floating information panel rendered above the target entity displays the item icon, quality border, entity name, and corresponding description.

[0299] See Figure 17 This figure is a schematic diagram illustrating the display of entity information indicating a high-quality level, provided in an embodiment of this application. For example... Figure 17 As shown, taking an entity with an epic quality level as an example, a more prominent border can be used to display entity information.

[0300] This application provides differentiated visual feedback for target entities of different quality levels. By displaying entity information with a corresponding appearance based on the target entity's quality level, users can quickly identify the quality of the target entity. This allows the entity information to not only provide relevant information about the entity but also represent its quality level. Users can then more quickly determine whether it is worthwhile to expend energy to continuously collect data from the target entity, reducing the probability of mistakenly collecting low-quality entities due to the inability to distinguish their quality levels. Furthermore, since users can quickly determine the quality level through the display appearance, the number of times they need to view the entity's quality level may be reduced, thereby reducing the number of interactions related to quality level.

[0301] Based on the above embodiments, by automatically triggering rarity judgment after the crosshair indicator hits a target entity, and conditionally displaying the entity information of the target entity according to the rarity judgment result, zero-additional operation information display can be achieved, allowing for instant access upon aiming. For high-rarity target entities, the terminal can instantly display a hover information bubble containing quality appearance, target entity name, and description information near the target entity, such as displaying different quality borders, text colors, or bottom frame styles according to the quality level. Users do not need to exit the current first virtual scene interface or open a details panel separately to obtain the attribute information of the target entity in the current interaction context. Compared to the method of needing to click to open a details panel separately, this reduces interactive operations such as opening and closing the panel and returning to the acquisition perspective. The path to obtaining target entity attribute information is shortened from aiming, exiting or interrupting the current operation, opening details, viewing details, closing details, and returning to the acquisition process to instant display after aiming, thereby improving information acquisition efficiency and target entity selection efficiency.

[0302] This application does not specifically limit the form of feedback after acquiring virtual resources. In one possible implementation, a second prompt message may be displayed in the first virtual scene interface when the continuous acquisition progress indicates that acquisition is complete.

[0303] The second prompt information is used to indicate the resource information of the acquired virtual resources. The resource information can describe the virtual resources actually acquired after this continuous data collection is completed. This application embodiment does not specifically limit the specific content included in the second prompt information. For example, the resource information may include at least one of the following: the name, quantity, quality level, rarity, purpose, source entity, acquisition time, whether it has been added to the inventory, and whether it has been included in the task progress.

[0304] For example, if a user obtains timber resources through continuous collection, the second prompt message can be displayed as "Acquired timber ×1".

[0305] Therefore, by displaying a second notification when the continuous data collection progresses to completion, the user can be directly informed of the successful acquisition of virtual resources, enhancing the overall feedback of the continuous data collection process. Users no longer need to frequently open their inventory or resource list to confirm whether the target entity's virtual resources have been acquired, reducing the number of confirmation operations and thus reducing computational resource consumption.

[0306] In one possible implementation, to prevent the second prompt from remaining in the first virtual scene interface for too long and obscuring the subsequent continuous data collection process, the second prompt can be controlled to disappear automatically after a preset display duration. For details, please refer to F1-F2.

[0307] F1: Displays a second prompt message with a preset duration in the first virtual scene interface.

[0308] The preset duration is the duration during which the second prompt message is displayed in the first virtual scene interface. The preset duration can be a fixed duration set by default, or it can be dynamically determined based on factors such as the type, quantity, quality level, rarity of the virtual resources, the length of the prompt message, and whether other acquired virtual resources exist.

[0309] As one implementation method, the higher the rarity of the virtual resource, the longer the corresponding preset duration. Similarly, the longer the second prompt message, the longer its preset duration.

[0310] For example, the second prompt message for virtual resources of normal rarity can be displayed for 1 second; the second prompt message for virtual resources of high rarity can be displayed for 2 seconds. Furthermore, if the second prompt message includes a long resource name or multiple resource information, the preset display duration can be appropriately extended to allow the user to read the second prompt message.

[0311] As one implementation method, the second prompt message can remain static during display, or it can have display effects such as fade-in, pop-up, zoom in, flash, or slight movement.

[0312] F2: After the second prompt message has been displayed for a preset duration, control the second prompt message to disappear from the first virtual scene interface.

[0313] The control of the disappearance of the second prompt message can be achieved by directly removing the second prompt message, or by using transition animations (such as fade-out, shrink, move up, move down, reduce transparency, etc.) to make the second prompt message disappear from the first virtual scene interface.

[0314] Therefore, by introducing a preset duration for the second prompt message and controlling its automatic disappearance after the preset duration, the user can perceive that the virtual resource has been acquired while preventing the second prompt message from occupying the display area of ​​the first virtual scene interface for an extended period. Furthermore, this display method is also suitable for scenarios where users need to continuously collect data from multiple entities, reducing the impact of the second prompt message's presence on subsequent operations.

[0315] In multi-entity acquisition scenarios, multiple second prompt messages may be generated within a short period. As an example, a user can acquire multiple target entities simultaneously with a single acquisition trigger operation. For instance, the selected area corresponding to the crosshair indicator may cover multiple entities to be acquired, or multiple target entities may be simultaneously captured by the virtual resource acquisition device at the end of a continuous acquisition animation, thereby acquiring the virtual resources corresponding to multiple target entities at once. As another example, a user can also continuously acquire multiple target entities within a short period. For instance, the user may sequentially align the crosshair indicator with multiple entities to be acquired and continuously execute acquisition trigger operations. Although the multiple target entities are acquired one by one, the time interval between two adjacent acquisitions is short, resulting in multiple second prompt messages used to indicate the resource acquisition results being generated closely in the first virtual scene interface. Therefore, if there are multiple second prompt messages, each indicating the acquisition of a virtual resource corresponding to a single target entity, this application proposes a specific implementation method for displaying second prompt messages in the first virtual scene interface, as detailed in G1-G2.

[0316] G1: Display each second prompt message sequentially in the first virtual scene interface according to a preset time interval.

[0317] The preset time interval is the display interval between two adjacent second prompt messages. The preset time interval can be a fixed interval or dynamically determined based on factors such as the number of second prompt messages, the average content length of each second prompt message, the average rarity of virtual resources, and the remaining display space of the first virtual scene interface. For example, the more second prompt messages there are, the shorter the preset time interval; the longer the average content length of each second prompt message, the higher the average rarity of virtual resources, and the smaller the remaining display space of the first virtual scene interface for the actual second prompt messages, the shorter the second preset time interval.

[0318] As one implementation method, when multiple second prompt messages need to be displayed, the terminal can add the multiple second prompt messages to the display queue in sequence according to a preset time interval, and display the multiple second prompt messages in the first virtual scene interface in the order of addition to the queue.

[0319] For example, if a user continuously obtains wood, stone, and energy fragments, the terminal can first display "Obtained wood ×1", then after a 0.3-second interval, display "Obtained stone ×1", and then after another 0.3-second interval, display "Obtained energy fragment ×1".

[0320] G2: For each second prompt message, after displaying the second prompt message, control the second prompt message to move along a preset direction in the first virtual scene interface until it disappears from the first virtual scene interface.

[0321] The preset direction is the direction in which the second prompt information moves from its display position to its disappearance position. This application does not specifically limit the preset direction. For example, the preset direction can be upward, downward, leftward, rightward, or it can be a direction towards the resource bar, inventory bar, taskbar, interface edge, or other preset area.

[0322] Specifically, for each second prompt message, the terminal can control the second prompt message to move along a preset direction after it is displayed, and make the second prompt message disappear from the first virtual scene interface when it moves to a position where it should disappear from the first virtual scene interface (this position can be a preset position or determined based on the display duration and the first virtual scene interface).

[0323] For example, when multiple second prompts need to be displayed, the terminal can control the multiple second prompts to scroll through the first virtual scene interface. For instance, the multiple second prompts can be displayed sequentially in a preset prompt area of ​​the first virtual scene interface according to their generation order, with later-displayed second prompts located adjacent to earlier ones. As the display progresses, the displayed second prompts can move as a whole along a preset direction, such as scrolling upwards. When a second prompt reaches the boundary of the preset prompt area, the terminal can control it to disappear from the first virtual scene interface. Thus, multiple virtual resource second prompts can be displayed continuously without completely filling the first virtual scene interface at once.

[0324] See Figure 18 This figure is a schematic diagram of displaying multiple second prompt messages according to an embodiment of this application. Taking the current display of two second prompt messages, with the preset direction being upward on the interface, as an example, after the second prompt messages are displayed, they can be controlled to move along the preset direction in the first virtual scene interface until they disappear from the first virtual scene interface, so that the subsequent third and fourth second prompt messages can be displayed.

[0325] Therefore, by displaying multiple second prompts sequentially at preset time intervals, interface congestion caused by multiple prompts appearing simultaneously can be avoided, allowing users to identify each acquired virtual resource one by one. By controlling each second prompt to move and disappear along a preset direction, the result of acquiring the virtual resource can be indicated without occupying the first virtual scene interface for an extended period. This reduces the likelihood of multiple prompts overlapping and causing users to be unable to identify resource information, thus reducing the need for users to reopen the resource list to verify resource information.

[0326] In one possible implementation, when displaying the second prompt message, the second prompt message can also be displayed with a display appearance corresponding to the quality level of the target entity.

[0327] Different quality levels can use different display appearances to differentiate the display of the second prompt information.

[0328] For example, the second prompt can be displayed as a text prompt. Text prompts can be divided into two styles: regular text prompts and special text prompts. Regular text prompts can be plain text prompts and can include two variations: a standard style and a gold style. Special text prompts can be item icon prompts and can be displayed using any of six background colors—white, green, blue, purple, orange, and red—depending on the quality level of the corresponding target entity.

[0329] See Figure 19 The figure is a schematic diagram of a special jump word provided in an embodiment of this application. In one possible implementation, if the target entity with a rarity greater than the rarity threshold is collected for the first time, a second prompt message can be displayed using a special jump word.

[0330] As an implementation approach, for high-quality target entities, differentiated display can enhance the feedback of results after acquisition, making it clear to users that high-quality virtual resources have been successfully acquired, thus increasing the sense of accomplishment in the game. For low-quality target entities, a lighter display appearance can be used to reduce unnecessary interface highlighting effects and rendering overhead.

[0331] For relevant details, please refer to the aforementioned embodiment of displaying entity information based on the quality level of the target entity, which will not be repeated here.

[0332] Therefore, by displaying a second prompt based on the quality level of the target entity and its corresponding visual appearance, the second prompt not only informs the user what virtual resource has been acquired, but also indicates the quality level of that virtual resource through its visual appearance. Users can quickly determine the quality level of the continuously acquired virtual resources without having to open the resource list, thus improving the user experience and reducing the number of operations required.

[0333] Based on the above embodiments, by using differentiated display of the second prompt information and staggered display methods, immediate positive feedback and a sense of ritual can be provided for virtual resource acquisition without interrupting the main acquisition process. Specifically, ordinary resources can use a standard pop-up text style, while high-rarity resources or special resources acquired for the first time can use a special pop-up text style, such as carrying an item icon, a quality border, or a highlighting effect. If multiple second prompt messages are generated in a short period of time in a multi-entity acquisition scenario, the multiple second prompt messages can pop up sequentially at preset time intervals, such as staggered display at 100-millisecond intervals, and move along a preset direction until they disappear. This avoids multiple prompt messages piling up and obscuring the first virtual scene interface, while allowing users to continuously perceive the acquisition results of multiple virtual resources, helping to maintain the user's continued motivation to participate.

[0334] In order to link the continuous collection results of a single target entity with the process of claiming reward resources, the first virtual scene interface may also include the collection progress of reward resources and the claimable status marker of reward resources. This application embodiment proposes a reward mechanism executed after S304, which can be referred to in H1-H2 for details.

[0335] H1: Update collection progress based on acquired virtual resources.

[0336] The reward resources are virtual resources used to reward users for completing the collection of virtual resources. For example, reward resources can be virtual items, material packs, etc. Collection progress indicates the user's progress regarding the reward resources. For example, collection progress can be numerical progress, percentage progress, etc. The claimable status flag indicates whether the reward resource is currently claimable. Furthermore, the claimable status flag can also be used to indicate the number of times the reward resource can be claimed.

[0337] Specifically, once the continuous collection progress is complete and the terminal has acquired the virtual resources corresponding to the target entity, the terminal can update the collection progress of the reward resources based on the acquired virtual resources.

[0338] This application does not specifically limit the method of updating the collection progress. For example, the update method may be to add the number of virtual resources acquired this time to the collection progress, or to determine the corresponding progress increase amount based on the type, quality level, rarity of the virtual resources or the attributes of the target entity before updating the collection progress.

[0339] For example, the reward collection progress display module can be located in the lower left corner of the first virtual scene interface to display the collection progress and the available reward status marker. The reward progress can be stored on the server side, incrementing each time the virtual resource corresponding to the target entity is successfully acquired, and unlocking the corresponding reward claiming permission when a preset progress threshold is reached. Based on this example, after a user completes a continuous collection, the terminal can synchronize the acquired virtual resources to the server, and the server can update the reward progress parameters. Alternatively, the terminal can first update the locally cached collection progress and then synchronize it with the server.

[0340] For example, the collection progress increases by 1 point for each virtual resource corresponding to a target entity that is fully acquired; if the target entity is rare, the collection progress can increase by more points; if the target entity corresponds to a special reward track, the collection results for that target entity can also be included in a specific reward tier.

[0341] H2: If the updated collection progress reaches the target progress, update the claimable status marker.

[0342] The target progress represents the progress conditions required for the reward resources to be claimed. The target progress can be a fixed threshold or multiple thresholds corresponding to different reward tiers.

[0343] Specifically, after the terminal updates the collection progress based on the acquired virtual resources, it can determine whether the updated collection progress has reached the target progress. If the updated collection progress has reached the target progress, it means that the user has met the conditions for claiming the reward resources, and the claimable status can be updated from unclaimable to claimable. If the updated collection progress has not yet reached the target progress, it can remain in the unclaimable status. As one implementation method, if the updated collection progress has not yet reached the target progress, it can also display how much is still needed to reach the target progress.

[0344] See Figure 20 This figure is a schematic diagram of a claimable status marker provided in an embodiment of this application. Taking the claimable status marker located on a virtual acquisition device as an example, a gift icon can be used to indicate whether a reward can be claimed, and when a reward can be claimed, the number of times it can be claimed is displayed, such as "×1" to indicate that it can be claimed once. In addition, prompts can be given to instruct the user on how to claim the reward, such as "Click the model, bubble, or F button to claim the reward".

[0345] Therefore, by displaying the collection progress and claimable status of reward resources in the first virtual scene interface, and updating the collection progress based on the acquired virtual resources after continuous collection is completed, the results of each continuous collection can be accumulated into the reward resource claiming conditions. Users can not only obtain the virtual resources corresponding to a single target entity, but also see the contribution of this continuous collection to the reward resource claiming progress, thereby enhancing the sense of purpose in continuous collection. Updating the claimable status directly when the collection progress reaches the target progress reduces the number of times users need to repeatedly open the reward page to confirm whether the reward is available, thus reducing the consumption of computing resources.

[0346] In one possible implementation, once the reward resources are available for collection, users can claim them through a claiming operation.

[0347] Specifically, if the "claimable" status flag indicates that the reward resource is available for claiming, the terminal can respond to the claiming operation for the reward resource and enter the claim success page. The claiming operation is used to trigger the claiming of the reward resource. For example, the claiming operation can be clicking the reward resource, pressing a keyboard key, triggering a gamepad button, or other operations that confirm the claiming of the reward resource. The claim success page is used to show the user that the reward resource has been successfully claimed. The claim success page may include at least one of the following: a claim success notification or a reward list.

[0348] For example, when the reward progress reaches the corresponding threshold, the reward collection module switches from an unclaimable state to a claimable state. Users can trigger the claiming operation by clicking on the reward model, clicking on the bubble, pressing the F key, etc. After claiming, a general congratulatory pop-up window will appear, displaying the reward list.

[0349] Therefore, because the claim entry point is displayed in association with the claimable status marker, users can directly complete the claim based on the prompts in the first virtual scene interface, thus reducing interface navigation and search operations. Simultaneously, by uniformly displaying the claim success notification and reward list on the claim success page, users are less likely to need to subsequently access their inventory or reward record page to check rewards, reducing computational resource consumption.

[0350] Based on the above embodiments, by tracking the collection progress and claimable status of reward resources, the results of a single target entity collection can be linked to long-term reward claiming goals, forming a long-term cyclical process of collection, accumulation, claiming, and re-collection. Specifically, the terminal or server can update the collection progress of reward resources based on the acquired virtual resources, and update the reward resources to a claimable status when the collection progress reaches the target progress or tier threshold. Furthermore, when there are unclaimed reward resources, users can be prompted to claim the reward resources through claimable status markers, guidance information from auxiliary virtual characters, map entry prompts, or head-up display prompts, thereby forming a cross-module pending-claim prompt mechanism, reducing the possibility of users missing reward resources, and enhancing users' motivation to continue the virtual resource acquisition process.

[0351] In one possible implementation, after the continuous acquisition progresses to completion and the acquisition of the virtual resources corresponding to the target entity, the real-time energy value obtained when the acquisition is completed can be restored.

[0352] Among them, the real-time energy value obtained when the collection is completed is the energy value remaining after the initial energy value is deducted from the energy value during the continuous collection process when the target entity is continuously collected.

[0353] As one implementation method, energy recovery can be achieved by adding a fixed energy value, or by determining an increase in energy value that is appropriate to the quality level of the target entity. For example, a target entity with a lower quality level corresponds to a smaller energy recovery value, while a target entity with a higher quality level corresponds to a larger energy recovery value.

[0354] Therefore, by restoring the real-time energy value after the data collection is completed, a certain amount of energy compensation can be provided to the user on the basis of the energy consumption of continuous data collection. This allows the user to obtain a certain amount of battery life after the data collection is completed. Based on this restoration mechanism, the energy value can both limit the continuous data collection and reduce the situation where the user has to wait for restoration frequently due to the energy value being depleted too quickly, thereby improving the smoothness of continuous data collection.

[0355] This application does not specifically limit the method of energy value deduction. In one possible implementation, when deducting the initial energy value as continuous acquisition progresses, the amount of energy value deduction for each time can be determined according to the energy value decay rate and the frame time interval.

[0356] The energy decay rate represents the rate at which the energy value decreases per unit time. The frame interval represents the time interval between adjacent rendering frames. The energy decay rate is determined based on at least one of the following: the attributes of the target entity, the distance between the target entity and the virtual resource acquisition device, or the visual state of the real-time energy value.

[0357] The attributes of a target entity may include its type, rarity, quality level, collection difficulty, required continuous collection duration, collectable quantity, and resource value. A virtual resource collection device is used to collect the virtual resources corresponding to the entity. The visual state of real-time energy values ​​may include at least normal, fatigued, and locked states.

[0358] Specifically, during continuous data acquisition, the terminal can determine the energy value decay rate based on at least one of the following: the attributes of the target entity, the distance between the target entity and the virtual resource acquisition device, or the visual state of the real-time energy value. Then, it subtracts the initial energy value according to the energy value decay rate and the frame time interval to obtain the real-time energy value. In other words, after each frame time interval, the terminal can calculate the energy value to be deducted based on the energy value decay rate and subtract that energy value from the current energy value to obtain the updated real-time energy value.

[0359] The above energy deduction method can be expressed by the following formula:

[0360]

[0361] in, The energy value deducted for each frame interval. The rate of energy decay. Let be the frame time interval. The energy value after each update can be expressed by the following formula:

[0362] in, This represents the energy value after each update. The current energy value, This is the energy value deducted for each frame interval.

[0363] As one implementation method, the energy decay rate can be determined based on the type of the target entity. For example, when the target entity is a basic resource such as common plants, wood, or stone, a lower energy decay rate can be used, while when the target entity is a more difficult-to-obtain entity such as ore, energy core, building components, or quest items, a higher energy decay rate can be used.

[0364] As another approach, the energy decay rate can be determined based on the rarity or quality level of the target entity. For example, when a target entity has quality levels such as white, green, blue, purple, orange, and red, the higher the quality level, the greater the energy decay rate can be, reflecting that high-quality target entities require more energy to complete continuous data collection.

[0365] As another implementation method, the energy decay rate can be determined based on the distance between the target entity and the virtual resource acquisition device. For example, the greater the distance between the target entity and the virtual resource acquisition device, the greater the energy decay rate can be. The closer the target entity and the virtual resource acquisition device are, the smaller the energy decay rate can be.

[0366] As another implementation method, the energy decay rate can be determined based on the visual state of the real-time energy value. For example, when the real-time energy value is in a normal state, it indicates that the current energy value is relatively sufficient, and the energy decay rate corresponding to the normal state can be used; when the real-time energy value is in a fatigued state, it indicates that the current energy value is low, and the energy decay rate corresponding to the fatigued state can be used.

[0367] As one example, the energy decay rate corresponding to the fatigue state can be greater than that corresponding to the normal state, in order to enhance the sense of tension when the energy value is low; as another example, the energy decay rate corresponding to the fatigue state can also be less than that corresponding to the normal state, in order to slow down the energy depletion rate when the energy value is low, thereby giving the user the opportunity to continue to complete the continuous collection of the current target entity.

[0368] Therefore, by deducting energy values ​​according to the energy decay rate and frame interval, the energy deduction process can be aligned with the actual execution time of continuous acquisition, avoiding inconsistencies in energy deduction across different device frame rates. Since the energy decay rate can be determined based on the target entity's attributes, the distance between the target entity and the virtual resource acquisition device, or the visual state of the real-time energy value, different energy decay rates can be set for different target entities, distances, and energy values. This allows energy deduction to dynamically change with the continuous acquisition scenario, thereby improving the strategic nature of the continuous acquisition process and the accuracy of energy deduction.

[0369] This application does not specifically limit how to enter the first virtual scene interface in resource acquisition mode. For example, one can enter the first virtual scene interface in resource acquisition mode by clicking on a task guide, activity entrance, resource acquisition entrance, or a non-player character (NPC) guide bubble. Alternatively, when preset resource acquisition conditions are met, the interface can automatically switch from the current virtual scene interface to the first virtual scene interface.

[0370] In one possible implementation, before displaying the first virtual scene interface in resource acquisition mode, the user can first enter the second virtual scene interface and then enter resource acquisition mode via a target capture point. See I1-I3 for details.

[0371] I1: Displays the second virtual scene interface.

[0372] The second virtual scene interface is the virtual scene interface displayed before entering the resource acquisition mode. For example, the second virtual scene interface can be a home scene interface, a map exploration interface, an open world scene interface, a virtual building scene interface, or other interfaces for the target virtual character to move and explore. The second virtual scene interface includes the target virtual character and the target capture point. The target virtual character is the user-controlled virtual character. The capture point is a coordinate point used to instruct the user to collect virtual resources, guiding the user into the resource acquisition mode. The target capture point is a capture point within the virtual scene. Different capture points correspond to different resource acquisition areas.

[0373] Specifically, the terminal can display the target virtual character and the target capture point in the second virtual scene interface. The user can control the target virtual character to move within the second virtual scene interface to approach the target capture point.

[0374] For example, the second virtual scene interface can be a third-person exploration interface of a virtual home. The target virtual character can walk in the home scene, and the target capture point can correspond to a resource acquisition area. The user needs to move the target virtual character to the vicinity of the target capture point before entering the resource acquisition mode.

[0375] I2: If the distance between the target virtual character and the target capture point is less than the distance threshold, a mode switching prompt will be displayed in the second virtual scene interface.

[0376] The distance threshold is used to determine whether the target virtual character has approached the target capture point. The mode switching prompt is used to indicate to the user that they can enter resource acquisition mode from the second virtual scene interface. For example, the mode switching prompt can be a button prompt, a button tooltip, a bubble prompt, an icon prompt, or a text prompt.

[0377] Specifically, the terminal can determine the distance between the target virtual character and the target capture point. If this distance is less than a distance threshold, it means that the target virtual character has entered the interactive range near the target capture point, and the terminal can display a mode switching prompt in the second virtual scene interface.

[0378] For example, when a user approaches the capture point, a key prompt appears on the screen, such as an F key interaction prompt on a PC.

[0379] I3: In response to the mode switching operation, enter the first virtual scene interface.

[0380] The mode switching operation is an action to enter a resource acquisition mode based on a mode switching prompt. The mode switching operation can be a button operation, a click operation, a touch operation, a gamepad button operation, a voice operation, or other interactive operations.

[0381] Specifically, after displaying the mode switching prompt in the second virtual scene interface, if the user performs the mode switching operation corresponding to the mode switching prompt, the terminal can display the first virtual scene interface.

[0382] For example, if the second virtual scene interface displays a prompt to press the F key to enter the capture mode switching, the user can press the F key as a mode switching operation. After the terminal responds to the F key operation, it can enter the resource acquisition mode from the second virtual scene interface and display the first virtual scene interface. The first virtual scene interface can display the target entities that can be acquired, the crosshair indicator, the energy progress bar, the acquisition operation key icons, the collection progress of reward resources, and other content.

[0383] Therefore, by first displaying a second virtual scene interface including the target virtual character and the target capture point, and then showing a mode switching prompt when the target virtual character approaches the target capture point, the entry point for the resource acquisition mode can be linked to a specific location in the virtual scene. Users no longer need to search for the resource acquisition entry point in the menu; instead, they can enter the first virtual scene interface by approaching the target capture point and triggering a mode switching operation, thus reducing the operational complexity of entering the resource acquisition mode. Simultaneously, the terminal only displays the mode switching prompt when the distance between the target virtual character and the target capture point is less than a distance threshold, reducing the likelihood of continuous display in non-interactive areas and thus lowering resource consumption caused by redundant information display.

[0384] In one possible implementation, when entering the first virtual scene interface in response to a mode switching operation, the second virtual scene interface, which is in a third-person perspective, can be switched to the first virtual scene interface, which is in a first-person perspective.

[0385] The first-person perspective displays the virtual scene from the viewpoint of the user-controlled virtual character. For example, in a first-person perspective, the user typically cannot see the complete virtual character itself, or only partial details such as the virtual character's hands or held virtual resource acquisition devices; the image more closely resembles the user's direct observation of the environment. The third-person perspective displays the virtual scene from a viewpoint other than the user-controlled virtual character. For example, in a third-person perspective, the user can typically see the virtual character itself and the virtual scene around it, facilitating observation of the virtual character's position, direction of movement, surrounding environment, and positional relationship with the target capture point.

[0386] As one implementation method, during the switching process, the terminal can adjust the position, orientation, field of view and rotation range of the virtual camera, and hide some of the head-up display (HUD) interface elements in the second virtual scene interface, while displaying interface elements such as the crosshair indicator, energy progress bar and acquisition operation key labels required for the resource acquisition mode.

[0387] For example, after a user presses the interaction key (mode switching operation), a state switch can be performed: the current HUD interface elements are hidden, the camera is switched from a third-person perspective to a first-person perspective, a crosshair indicator is rendered in the center of the screen, an energy progress bar is rendered at the bottom of the screen, and key icons for the resource acquisition operation, such as the left mouse button or SPACE key, are rendered at the bottom of the screen. After the user presses the F key in the second virtual scene interface to enter the resource acquisition mode, the terminal can switch from the second virtual scene interface displaying the target virtual character to the first virtual scene interface where the user observes the resource acquisition area from their perspective, allowing the user to aim at the target entities scattered within the resource acquisition area using the crosshair indicator in the center of the screen.

[0388] Therefore, by switching from a third-person perspective to a first-person perspective when entering resource acquisition mode, users can obtain more suitable perspectives during the movement and exploration phases and the continuous acquisition phases, respectively. The third-person perspective makes it easier for users to observe the positional relationship between the target virtual character and the target capture point in the second virtual scene interface, while the first-person perspective makes it easier for users to accurately aim at the target entity and perform continuous acquisition in the first virtual scene interface.

[0389] In one possible implementation, for a game scenario, before entering the second virtual scene interface, the user can first select a target capture point through the game map interface in order to determine the resource acquisition area they wish to enter from multiple capture points, as detailed in J1-J2.

[0390] J1: Enter the game map interface.

[0391] The game map interface is an interface that displays the game map. The game map interface includes multiple capture points, including the target capture point.

[0392] Specifically, the terminal can respond to the user's action of opening the game map by displaying the game map interface and showing multiple capture points on the game map interface. Each capture point can correspond to a resource acquisition area, and multiple entities to be acquired can be distributed within the resource acquisition area.

[0393] See Figure 21 This figure is a schematic diagram of a game map interface provided in an embodiment of this application. Figure 21As shown, the game map interface can include a game map area, a function entry area, a map zoom control, and multiple capture points. These capture points can be displayed as preset icons at different locations within the game map area. The game map area displays the map content corresponding to the virtual scene, which can include map elements such as roads, building areas, open areas, and functional areas. The function entry area can include multiple function entries such as menu entries, map entries, and task entries. Users can switch to the corresponding function page or view corresponding function information by triggering different function entries. The map zoom control can be used to adjust the display ratio of the map content in the game map area. J2: In response to the selection of a target capture point, enter the second virtual scene interface.

[0394] The selection operation is used to select a target snap point. For example, the selection operation can be a click operation, a touch operation, a mouse hover confirmation operation, a gamepad selection operation, a shortcut key selection operation, or other operations that can select a target snap point.

[0395] Specifically, in the game map interface, if the user selects a target capture point among multiple capture points, the terminal can enter the second virtual scene interface corresponding to that target capture point.

[0396] Therefore, by first displaying multiple capture points on the game map interface and then entering the second virtual scene interface in response to the selection of a target capture point, users can select the resource acquisition area before entering the resource acquisition mode. Only after the user selects a target capture point does the corresponding second virtual scene interface need to be loaded or displayed, reducing resource consumption caused by loading and rendering scenes in unselected areas.

[0397] In one possible implementation, to ensure users are aware of the target capture point's information before entering the second virtual scene interface, a details pop-up can be displayed after the user selects the target capture point, and the second virtual scene interface can be accessed only after the user confirms the selection. See K1-K2 for details.

[0398] K1: In response to the selection of a target capture point, display a details pop-up window in the game map interface.

[0399] The details pop-up is an interface element displayed in the game map interface. It includes a confirmation control and detailed information about the target capture point. The confirmation control is used to confirm entry into the second virtual scene interface corresponding to the target capture point. For example, the confirmation control can be a button, icon, text entry, shortcut key hint, or other triggerable control. The detailed information about the target capture point describes the relevant content of the resource acquisition area corresponding to the target capture point. For example, the detailed information about the target capture point can include what entities can be collected in that resource acquisition area, an image of the capture point, etc.

[0400] Specifically, after a user selects a target capture point in the game map interface, the terminal may not immediately enter the second virtual scene interface. Instead, it may first display a details pop-up window corresponding to the target capture point, allowing the user to confirm the detailed information of the target capture point before entering the second virtual scene. For example, after seeing the icon corresponding to the target capture point in the game map interface, the user can click on the icon, and then a side details pop-up window will pop up on the right side of the map. This details pop-up window displays the image, description, and geographical location of the capture point, and provides a confirmation control.

[0401] As one implementation method, in response to the selection of the target capture point, one can directly enter the first virtual scene interface in resource acquisition mode.

[0402] K2: In response to the confirmation control, enter the second virtual scene interface.

[0403] Specifically, after the details pop-up window is displayed, if the user triggers the confirmation control, the terminal can confirm that the user wants to enter the resource acquisition area corresponding to the target capture point, thereby entering the second virtual scene interface.

[0404] For example, after a user clicks the "Go" button (a confirmation control) in the details pop-up window, the terminal can automatically navigate the target virtual character to the vicinity of the target capture point, or directly switch to the second virtual scene interface where the target capture point is located. After entering the second virtual scene interface, the user can continue to control the target virtual character to approach the target capture point, and trigger the entry into resource acquisition mode when the distance condition is met.

[0405] See Figure 22 This figure is a schematic diagram of a details pop-up window provided in an embodiment of this application. Figure 22As shown, taking capture point 3 as the target capture point as an example, in response to the user's selection of capture point 3, the terminal can display a details pop-up window in the game map interface. The details pop-up window can be displayed in the right-hand area of ​​the game map interface, or it can be displayed in the bottom area, floating area, or near the target capture point, depending on the interface layout; this embodiment does not specifically limit this. The details pop-up window may include the name of the target capture point, an image of the resource acquisition area corresponding to the target capture point, its geographical location, resource description, and confirmation controls, etc. For example, Figure 22 The details pop-up window shows that the name of capture point 3 is Home Island, and displays the scene content of the resource acquisition area corresponding to capture point 3 through pictures. It also provides text prompts that resources such as wood and stone can be obtained in this resource acquisition area.

[0406] like Figure 22 As shown, the details pop-up window can also include a confirmation control, such as a "go to" control. After the user triggers the "go to" control, the terminal can respond to the triggering operation of the confirmation control and enter the second virtual scene interface corresponding to capture point 3.

[0407] Therefore, by displaying a details pop-up window before entering the second virtual scene interface, users can confirm their selection of a target capture point. Users can determine whether to enter the capture point based on its detailed information, thus reducing the probability of accidentally entering the wrong capture point, entering and then exiting, and having to reselect. This reduces the consumption of computing and rendering resources during scene switching.

[0408] In one possible implementation, the second virtual scene interface may also include an auxiliary virtual character and guidance information associated with the auxiliary virtual character, the guidance information being used to guide the target virtual character into the resource acquisition mode.

[0409] The auxiliary virtual character is a virtual character used to provide guidance, prompts, task instructions, or entry prompts to the user in the second virtual scene interface. For example, the auxiliary virtual character can be an NPC, a virtual pet, etc. Guidance information is used to guide the user on how to enter the resource acquisition mode. For example, guidance information can be at least one of the following: text bubbles, voice prompts, icon prompts, arrow directions, light effects, task prompts, and button prompts.

[0410] Specifically, in the second virtual scene interface, the terminal can display an auxiliary virtual character near the target capture point and display guidance information associated with the auxiliary virtual character.

[0411] For example, when a user enters the vicinity of a capture point, the NPC character next to the capture point can send out a voice bubble to guide the user, such as "Master, come and play the capture gameplay"; after the user approaches the capture point, key prompts appear on the screen, such as the F key prompting to enter the resource acquisition mode.

[0412] Therefore, by setting up an auxiliary virtual character and its associated guidance information in the second virtual scene interface, the entry point to the resource acquisition mode can be presented to the user in a contextualized manner. Users can complete the steps of approaching the capture point and triggering the mode switch based on the guidance information of the auxiliary virtual character without relying on menu instructions, thereby reducing the operational threshold for entering the resource acquisition mode.

[0413] In one possible implementation, when there are reward resources waiting to be claimed in the second virtual scene interface, the second virtual scene interface also includes guidance information associated with the auxiliary virtual character.

[0414] The "pending claim" status indicates that the reward resources have met the claiming conditions but have not yet been claimed by the user. In this case, the guidance information associated with the auxiliary virtual character can not only guide the user into resource acquisition mode but also notify the user of the existence of pending reward resources.

[0415] Specifically, the terminal can detect whether there are any reward resources waiting to be claimed in the second virtual scene interface. If there are reward resources waiting to be claimed, the terminal can display guidance information on the auxiliary virtual character to prompt the user to view and claim the reward resources.

[0416] For example, when there are unclaimed reward resources at a capture point, the NPC character next to the capture point in the scene will emit a chat bubble to guide the player. For example, "There are rewards to claim," "Come and see the capture rewards," "Press F to claim the rewards," etc.

[0417] Therefore, users can promptly discover rewards to be claimed by using the guidance information provided by the virtual avatar, reducing the chance of missing out on reward resources.

[0418] See Figure 23 This figure is a schematic diagram of a second virtual scene interface provided in an embodiment of this application. Figure 23 As shown, the second virtual scene interface may include a target virtual character, a target capture point, an auxiliary virtual character, and guidance information associated with the auxiliary virtual character.

[0419] The auxiliary virtual character can be located near the target capture point and display associated guidance information. This guidance information can be displayed as a text bubble to guide the target virtual character into resource acquisition mode. For example, Figure 23The auxiliary virtual character displays a message saying "It has an owner, come and play the capture game!" to prompt the user that they can go to the target capture point and enter resource acquisition mode. Simultaneously, the second virtual scene interface can also display key prompts corresponding to the target capture point, such as "Press F to enter the capture mini-game," to indicate that the user can enter resource acquisition mode by pressing the corresponding key after approaching the target capture point.

[0420] Furthermore, such as Figure 23 As shown, when reward resources are available for collection in the second virtual scene interface, the guidance information associated with the auxiliary virtual character can also be used to remind the user of these unclaimed reward resources. For example, the auxiliary virtual character can display a text bubble indicating that a reward is available to collect, reminding the user to check and collect the reward resources. Therefore, the guidance information associated with the auxiliary virtual character can not only guide users into resource acquisition mode but also remind them to collect reward resources that have met the collection conditions but have not yet been collected, thereby reducing reward omissions.

[0421] In addition, such as Figure 23 As shown, the second virtual scene interface may also include HUD interface elements. HUD interface elements can be function entry icons displayed at the top of the second virtual scene interface, used to support other interactive operations by the user within the second virtual scene interface.

[0422] In one possible implementation, the first virtual scene interface may also include key identifiers for data acquisition operations, which indicate the keys used to perform data acquisition trigger operations.

[0423] The key input indicators are UI elements that prompt the user to perform the key input action. For example, key input indicators can display specific keyboard keys, mouse buttons, gamepad buttons, touch buttons, virtual buttons, key combinations, or other input methods. The disabled state indicates that although the key input indicator exists, the corresponding key input action is temporarily unavailable.

[0424] Specifically, in the first virtual scene interface, the terminal can display key icons for data acquisition operations to prompt the user on which input method should be used to trigger continuous data acquisition.

[0425] For example, after entering resource scavenging mode, scavenging operation key indicators, such as left mouse button or SPACE key tooltips, can be rendered at the bottom of the screen. When the user aims at a target, they can trigger the acquisition of the virtual resource corresponding to the target entity by pressing and holding the left mouse button or SPACE key.

[0426] Furthermore, if the target entity is within the selected range and the initial energy value is less than or equal to the first energy threshold, in response to the acquisition trigger operation, the terminal can display the status of the acquisition operation key identifier as disabled.

[0427] For example, if the user has already hit the target entity with the crosshair indicator, but the initial energy value is 0, the terminal will not start continuous acquisition even if the user presses the left mouse button or the SPACE button. Instead, the acquisition operation key identifier will be displayed as disabled. This disabled state can also be displayed in conjunction with the aforementioned first prompt message and the locked state of the crosshair indicator to indicate that continuous acquisition cannot be performed under the current circumstances.

[0428] Furthermore, the energy value can be restored after the acquisition operation key identifier is disabled. When the restored energy value is greater than the first energy threshold and the target entity is still within the selected range, the terminal can switch the status of the acquisition operation key identifier from disabled to enabled. The enabled status indicates that the energy conditions for continuous acquisition have been met, and the user can execute the acquisition trigger operation through the key indicated by the acquisition operation key identifier.

[0429] Therefore, by switching the key identifier for the data collection operation to an available state after the energy value is restored, users can intuitively perceive that the data collection function has been unlocked, reducing the user's judgment cost regarding whether the data collection trigger operation can be performed, and improving the interactive continuity of the continuous data collection process.

[0430] Therefore, by displaying the key icons for data acquisition operations in the first virtual scene interface, the cost for users to learn how to trigger data acquisition operations can be reduced, allowing users to directly know which input method to use to perform continuous data acquisition. Furthermore, when the initial energy value is insufficient, the key icons for data acquisition operations are displayed as disabled, so that users can understand at the operation entry point that the current operation is unavailable, reducing the number of times users repeatedly try to start continuous data acquisition, thereby reducing the consumption of computing resources.

[0431] In one possible implementation, the trigger operation can be a first press operation where the press duration reaches a threshold. To guide the user to correctly execute this first press operation, a third prompt message can be displayed if the user's press operation does not reach the duration threshold.

[0432] The first press operation is a press operation whose duration reaches a certain threshold, used to perform continuous data collection on the target entity, such as a long press. The duration threshold is a time threshold used to determine whether a press operation is a valid data collection trigger operation. The second press operation is a press operation whose duration is less than the duration threshold, i.e., a short press operation. The third prompt message indicates that the data collection trigger operation is the first press operation, i.e., prompting the user to continue pressing.

[0433] As one implementation method, the terminal can collect the duration of user presses on keypads, controls, mouse buttons, keyboard buttons, or gamepad buttons to determine the press duration, and compare this duration with a duration threshold. If the press duration reaches the threshold, it can be determined that the user has performed a first press operation, and continuous data collection can be performed. If the press duration is less than the threshold, it can be determined that the user has performed a second press operation, at which point the terminal can display a third prompt message to guide the user to perform the correct long press operation.

[0434] For example, after a user aims at a target entity, the acquisition of the target entity is triggered by a first press operation (such as long-pressing the left mouse button or the SPACE key). When the user presses briefly instead of long-pressing, the progress bar increases by a preset length and then bounces back, accompanied by an animation prompt, to suggest to the user that a long-press operation is required and to reduce the learning cost.

[0435] Therefore, by limiting the data collection trigger to the first press operation that reaches a certain duration threshold, we can avoid accidental touches, short presses, or random clicks that directly trigger continuous data collection. When the user performs a second press operation, a third prompt message is displayed, making the user understand that a long press is required to complete continuous data collection. This reduces the chance of inadvertently starting the continuous data collection process due to invalid short presses, thereby reducing the consumption of computing and rendering resources.

[0436] This application does not specifically limit the scene type of the first virtual scene interface, nor does it specifically limit the specific manifestation of continuous data collection on the target entity. Different types of first virtual scene interfaces can correspond to different continuous data collection methods.

[0437] For example, in a virtual sky scene, the entity to be acquired can float in the virtual sky scene, such as floating energy bodies, fragments, props, material balls, etc. The user can use the virtual resource acquisition device to perform absorption on the target entity to perform continuous acquisition, so that the target entity gradually approaches the crosshair indicator or the user side area, and acquires the corresponding virtual resource when the progress of continuous acquisition reaches the acquisition completion.

[0438] As one implementation method, the absorption rate of a target entity can be determined based on the entity's attributes. These attributes may include the entity's rarity, quality level, resource type, collection difficulty, resource value, distance between the entity and the virtual resource acquisition device, the entity's size, and the remaining collectable quantity.

[0439] For example, the higher the rarity or quality level of the target entity, the slower the absorption speed can be, reflecting that high-rarity or high-quality target entities require a longer continuous collection process. The greater the distance between the target entity and the virtual resource acquisition device, the slower the absorption speed can be. The higher the difficulty of collecting the target entity, the higher the resource value, or the greater the remaining collectable quantity, the slower the absorption speed can be, thus requiring users to invest more time and energy in the continuous collection process.

[0440] In a virtual forest scenario, entities to be acquired can be planted within the virtual forest, such as trees, fruits, plants, flowers, and herbs. Users can use virtual tools to perform actions like felling, harvesting, and cutting to continuously collect resources. For example, after a user presses and holds the collect button, the target plant can gradually glow, shake, or decompose. The energy value is deducted as the continuous collection progresses. When the continuous collection is completed, wood resources, fruit resources, or plant material resources are obtained.

[0441] In a virtual mine scenario, entities to be acquired can be embedded within the virtual mine environment, such as ores, crystals, rocks, or energy veins. Users can perform continuous acquisition such as drilling, crushing, cutting, or extraction using virtual drilling devices, crushing devices, or acquisition tools. For example, as continuous acquisition progresses, the target ore may gradually develop cracks, break apart, or release light effects, while its energy value is gradually deducted until the acquisition of mineral or crystal resources is completed.

[0442] In a virtual water environment, the entity to be acquired can be located on or underwater, such as floating objects, underwater props, fish resources, or sunken treasure chests. Users can continuously collect these entities through methods such as fishing, salvaging, towing, purifying, or storing. For example, after a user continuously presses the collect button, the target entity can be gradually pulled closer, float to the surface, or enter the collection area, and after collection, it will be converted into the corresponding virtual resource.

[0443] In one possible implementation, the first virtual scene interface can be the interface of a virtual sky scene, with the entity to be acquired floating in the virtual sky scene.

[0444] The virtual sky scene is a virtual scene with floating space. Entities to be acquired can float in the virtual sky scene; for example, they can be displayed by hovering, drifting, rising, falling, rotating, circling, moving randomly, or moving along a preset trajectory. A preset deployment strategy is used to indicate how to deploy the entities to be acquired.

[0445] Specifically, when the first virtual scene interface is a virtual sky scene, the terminal can display multiple floating entities to be acquired within the virtual sky scene. The user can select a target entity and continuously acquire the virtual resources corresponding to the target entity.

[0446] As one implementation method, when the target entity has been collected or the number of entities to be acquired in the virtual sky scene is lower than a preset threshold, the terminal can deploy new entities to be acquired into the virtual sky scene according to a preset deployment strategy.

[0447] As one implementation method, a preset delivery strategy is used to maintain the number and distribution density of target entities that can be continuously acquired in the virtual sky scene.

[0448] For example, a preset deployment strategy could be to deploy new entities to be acquired at time intervals, such as generating at least one new entity to be acquired in the virtual sky scene every certain period of time. Alternatively, a preset deployment strategy could be to deploy new entities to be acquired based on quantity conditions, such as deploying new entities to be acquired when the number of entities to be acquired in the virtual sky scene falls below a preset quantity threshold. A preset deployment strategy could also be to deploy new entities to be acquired based on regional distribution, such as deploying new entities in front of the user's current field of view, at the edge of the virtual sky scene, in the air area corresponding to the target capture point, or in a preset refresh area. Furthermore, a preset deployment strategy could determine the entities to be acquired based on factors such as the user's current energy value, reward progress, the rarity of the target entity, and the number of times continuous collection has been completed.

[0449] For example, after a user has continuously collected multiple ordinary target entities, a higher-quality entity to be acquired can be deployed; when the distribution of target entities in a virtual sky scene is too concentrated, a new entity to be acquired can be deployed to a more open area to maintain the distribution density of floating objects in the scene.

[0450] Therefore, by setting the first virtual scene interface to a virtual sky scene and deploying new entities to be acquired into the virtual sky scene according to a preset deployment strategy, the continuous acquisition process can have a continuous source of entities. After completing the continuous acquisition of a target entity, the user can continue to discover new entities to be acquired in the virtual sky scene. Furthermore, the preset deployment strategy can also control how entities to be acquired are deployed, allowing for more accurate control over the terminal's deployment process. For example, controlling the number of entities can reduce the rendering pressure caused by deploying too many entities at the same time, and controlling the distribution density can reduce the number of times the user has to frequently move the viewpoint to find the target due to a lack of entities.

[0451] The methods described in the above embodiments are illustrated below through an exemplary backend implementation. See [link to relevant documentation]. Figure 24This figure is a schematic diagram of a hardware environment provided in an embodiment of this application.

[0452] The hardware environment includes a terminal 2400, a server 2410, and a communication network 2420. The terminal 2400 and the server 2410 can interact with each other through the communication network 2430.

[0453] Terminal 2400 can be a device used by a user. For example, terminal 2400 can include, but is not limited to, personal computers, game consoles, smartphones, tablets, wearable devices, virtual reality devices, etc.

[0454] The terminal 2400 may include a processor 2401, a memory 2402, a display unit 2403, an input acquisition unit 2404, a graphics processing unit 2405, an energy value attenuation calculation unit 2406, and a communication module 2407.

[0455] The processor 2401 can be used to execute control logic during the virtual resource acquisition process. For example, the processor can be used to determine whether the target entity is within the selected range, respond to the acquisition trigger operation, control the execution state of continuous acquisition, control the state switching of the crosshair indicator, and control the updating of relevant interface elements in the first virtual scene interface.

[0456] The memory 2402 can be used to store relevant data during the virtual resource acquisition process. For example, the memory 2402 can be used to store energy value parameters, target entity attribute cache data, crosshair indicator status parameters, reward resource collection progress cache data, etc.

[0457] The display unit 2403 can be used to display visual content during the virtual resource acquisition process. For example, the display unit 2403 can be used to display a first virtual scene interface, a crosshair indicator, an energy progress bar, entity information of the target entity, second prompt information, key identifiers for acquisition operations, collection progress of reward resources, and available status markers, etc.

[0458] The input acquisition unit 2404 can be used to acquire user input operations. For example, the input acquisition unit 2404 can acquire click operations, long press operations, release operations, mouse movement operations, keyboard key operations, gamepad key operations, touch operations, etc.

[0459] The graphics processing unit 2405 can be used to perform graphics processing tasks during the virtual resource acquisition process. For example, the graphics processing unit 2405 can be used to perform virtual scene interface rendering, target entity rendering, continuous acquisition animation rendering, particle effect rendering, interface control overlay rendering, etc.

[0460] The energy value attenuation calculation unit 2406 can be used to perform energy value deduction related processing during continuous acquisition. For example, the energy value attenuation calculation unit 2406 can calculate the energy value deduction amount based on the energy value attenuation rate and frame time interval, and can also be used to perform first energy threshold judgment, fatigue state judgment, lock state judgment, and energy value recovery calculation in non-continuous acquisition state.

[0461] The communication module 2407 can be used to interact with the server. For example, the communication module 2407 can be used to obtain attribute configuration data, resource output data, reward progress data, etc. of the target entity from the server 2410, and can also be used to send data such as virtual resource acquisition results and reward resource claiming results to the server 2410.

[0462] Server 2410 may include a service processor 2411, a service storage 2412, a target attribute configuration database 2413, a reward progress management module 2414, a rarity determination engine 2415, a resource production control unit 2416, and a service communication module 2417.

[0463] The service processor 2411 can be used to execute business processing logic on the server 2410 side. The service memory 2412 can be used to store computer programs and business data on the server 2410 side. The target attribute configuration database 2413 can be used to store attribute configuration data of target entities, such as the target entity's location, type, rarity, quality level, resource type, and required continuous collection duration. The reward progress management module 2414 can be used to manage the collection progress and claimability status of reward resources. The rarity determination engine 2415 can be used to determine the rarity of the target entity based on its attribute configuration data. The resource production control unit 2416 can be used to determine the virtual resources corresponding to the target entity after collection. The service communication module 2417 can be used to interact with the communication module 2407 of the terminal 2400.

[0464] The following is through Figure 25 This section introduces a background process that runs on the aforementioned hardware environment. See S1-S20 for details:

[0465] In S1, the virtual resource acquisition process begins. For example, a user can trigger an operation to enter resource acquisition mode within a virtual scene. The input acquisition unit 2404 acquires the scene entry signal generated by this operation and transmits the scene entry signal to the processor 2401. Here, the resource acquisition mode is a type of resource acquisition mode, and the resource acquisition device is a type of virtual resource acquisition device.

[0466] In S2, in response to the scene entry signal, terminal 2400 switches to a first-person perspective and hides the head-up display (a specific implementation of the first virtual scene interface corresponding to entering the resource acquisition mode). Specifically, after receiving the scene entry signal collected by input acquisition unit 2404, processor 2401 can send a head-up display hiding command to display unit 2403 to hide the head-up display elements displayed before entering the resource acquisition mode. At the same time, processor 2401 can switch the rendering mode of the virtual camera from third-person perspective mode to first-person perspective mode, so that display unit 2403 displays the first virtual scene interface in resource acquisition mode. Processor 2401 can also set the pitch angle range limit parameter of the view rotation in the first-person perspective and write the pitch angle range limit parameter into memory 2402 so that the view rotation range can be limited when adjusting the virtual camera orientation according to the user's mouse displacement signal, touch sliding signal or gamepad joystick signal.

[0467] In S3, terminal 2400 loads energy value parameters and displays an energy progress bar corresponding to the initial energy value. Specifically, processor 2401 can read the real-time energy value and the target energy limit value from memory 2402 and calculate the corresponding energy ratio. Processor 2401 can determine the visual state of the initial energy value based on the energy ratio R: if R is greater than 0.2, the visual state corresponding to the initial energy value is determined to be normal; if R is greater than 0 and less than or equal to 0.2, the visual state corresponding to the initial energy value is determined to be fatigued; if the real-time energy value is 0, the visual state corresponding to the initial energy value is determined to be locked. Processor 2401 can send an energy progress bar rendering instruction to display unit 2403. This energy progress bar rendering instruction can include parameters such as the current energy value, the energy limit value, and the visual state type, causing display unit 2403 to display the energy progress bar in the first virtual scene interface. This energy progress bar can serve as a display method for the initial energy value, with its fill length representing the initial energy value, the progress bar outline representing the energy limit value, and the display style representing the normal state, fatigued state, or locked state. Simultaneously, the processor 2401 can request attribute configuration data of target entities within the current resource acquisition area from the server 2410 via the communication network 2420 through the communication module 2407. The server 2410 can receive the request through the service communication module 2417, read the attribute configuration data of the target entity from the target attribute configuration database 2413, and then return it to the terminal 2400 through the service communication module 2417. After receiving the data, the terminal 2400 can cache the attribute configuration data in the memory 2402. The attribute configuration data of the target entity may include parameters such as the target entity's location coordinates, rarity, quality level, resource type, required continuous acquisition duration, and resource quantity.

[0468] In S4, the terminal 2400 renders the crosshair indicator in the center of the screen and updates the viewing angle in response to the mouse displacement signal. Specifically, the processor 2401 can control the display unit 2403 to display the crosshair indicator at a fixed position in the center of the screen of the first virtual scene interface. The initial state of the crosshair indicator can be an unaimed state. The crosshair indicator is used to indicate the selected range of the current user. The user can adjust the orientation of the virtual camera so that the selected range corresponding to the crosshair indicator faces different entities to be acquired. For example, the input acquisition unit 2404 can continuously acquire mouse displacement increment signals Δx and Δy and transmit the mouse displacement increment signals to the processor 2401. The processor 2401 can map Δx to the rotation increment of the virtual camera around the Y-axis, that is, the change in viewing angle in the horizontal direction; and map Δy to the rotation increment of the virtual camera around the X-axis, that is, the change in viewing angle in the vertical direction. The processor 2401 can also perform boundary detection by combining the pitch angle range limit parameters stored in the memory 2402. If the calculated rotation angle exceeds the preset maximum rotation range, the rotation angle is truncated to the boundary value. The graphics processing unit 2405 can render the 3D scene in the first virtual scene interface according to the updated viewing angle.

[0469] In S5, the terminal 2400 determines whether the crosshair ray has hit a target entity. Specifically, the processor 2401 can construct a detection ray emanating from the crosshair position along the current viewing direction in each rendering frame, based on the position of the crosshair indicator in the center of the screen and the current viewing direction. The processor 2401 can traverse the list of target entities cached in the memory 2402 and perform intersection detection between the detection ray and the collision area of ​​the target entity based on the position coordinates and collision area of ​​the target entity. If the detection ray hits a target entity, it can be determined that the crosshair indicator has hit the target entity, the target entity is within the selected range, and proceed to S6. If the detection ray does not hit any target entity, the crosshair indicator remains unaimed, the processor 2401 can return to S4, continue to update the viewing direction based on the user's mouse displacement signal, and continue to perform detection in the next frame.

[0470] In S6, the terminal 2400 highlights the hit target entity and queries the rarity of the target entity. Specifically, when the processor 2401 determines that the crosshair ray has hit the target entity, it can send a target highlight rendering command to the graphics processing unit 2405, causing the graphics processing unit 2405 to highlight the hit target entity. For example, display effects such as highlight shaders, outer contour lines, edge glows, brightness enhancements, or checkboxes can be applied to the target entity to indicate to the user that the target entity has been selected. At the same time, the processor 2401 can read the rarity attribute parameters, quality level, resource type, resource quantity, and other attribute data of the target entity from the memory 2402. If the rarity attribute of the target entity is not cached locally, the processor 2401 can also send a query request to the server 2410 through the communication module 2407, and the rarity determination engine 2415 or the target attribute configuration database 2413 of the server 2410 will return the rarity attribute of the target entity. At this time, the processor 2401 can control the crosshair indicator to switch from the unaimed state to the aimed state.

[0471] In S7, the terminal 2400 determines whether to display the entity information of the target entity based on whether the crosshair ray hits the target entity. Specifically, if the crosshair ray still hits the target entity, the processor 2401 can determine whether to display the hover information bubble based on the rarity of the target entity. If the rarity of the target entity is greater than or equal to a preset high rarity threshold, or if the target entity is configured as a special target, then the target entity meets the conditions for displaying entity information, and the process proceeds to S8. If the rarity of the target entity is lower than the high rarity threshold, or if the crosshair ray no longer hits the target entity, the processor 2401 can either not display or hide the hover information bubble, and proceed to S9 to perform real-time energy value judgment. Thus, the terminal 2400 can display entity information only when the target entity has high cue value, avoiding the frequent triggering of information bubbles by ordinary target entities and thus obscuring the first virtual scene interface.

[0472] In S8, the terminal 2400 renders a target hover information bubble (i.e., one way to display entity information of the target entity). Specifically, the processor 2401 can construct a rendering data package for the hover information bubble based on the target entity's attribute configuration data. This rendering data package may include prop icon texture identifiers, target entity name, target entity description, rarity level, quality level, quality border parameters, and font color parameters, etc. As one implementation, the processor 2401 can display the entity information of the target entity with a display appearance corresponding to the quality level. For example, different quality levels such as white, green, blue, purple, orange, and red can correspond to different quality borders, bottom border styles, or name font colors. If the description string of the target entity exceeds a preset length threshold, the processor 2401 can also truncate the description string and append an ellipsis marker to the truncated description string. The display unit 2403 can display the hover information bubble above the target entity model in a manner facing the virtual camera, according to the 3D interface rendering instructions sent by the processor 2401, and update it in real time as the target entity's position changes. When the crosshair indicator moves away from the target entity, or the target entity no longer meets the high rarity display conditions, the processor 2401 can send a bubble hiding command to the display unit 2403 to hide the hover information bubble.

[0473] In S9, the terminal 2400 determines whether the real-time energy value is greater than 0 (a first energy threshold). Specifically, the processor 2401 can read the current real-time energy value from the memory 2402 and determine whether the real-time energy value is greater than the first energy threshold. The diagram uses 0 as an example for the first energy threshold, so the judgment condition can be expressed as whether the real-time energy value is greater than 0. If the real-time energy value is less than or equal to 0, it indicates that the current energy value is insufficient to support continuous acquisition of the target entity, and the process proceeds to S10. If the real-time energy value is greater than 0, it indicates that the energy conditions for starting or continuing continuous acquisition are met, and the process proceeds to S11, preparing to receive the user's acquisition trigger operation.

[0474] In S10, the terminal 2400 switches the crosshair indicator to a locked state and indicates insufficient energy. Specifically, if the target entity is within the selected range, but the real-time energy value is less than or equal to a first energy threshold, the processor 2401 can control the display unit 2403 to display the crosshair indicator in a locked state. The locked state can be grayed out, a lock icon, a prohibited icon, an untriggerable style, or other locked styles. When the input acquisition unit 2404 detects a user's click operation, press operation, or other acquisition trigger operation, the processor 2401 can control the display unit 2403 to display a first prompt message, which indicates that the current energy value is insufficient. For example, the first prompt message can be "Insufficient energy value, waiting for energy value to recover." At the same time, the processor 2401 can also control the acquisition operation key identifier to be displayed in a disabled state, for example, switching the acquisition operation key identifier corresponding to the left mouse button or SPACE key to a grayed-out, locked, or untriggerable style. Afterward, the terminal 2400 enters a waiting state, and the energy value is restored by the background energy value recovery process in S19. When the real-time energy value recovers to a level greater than the first energy threshold, the processor 2401 can automatically unlock the state, restore the crosshair indicator and the acquisition operation key mark to the available state, and return to S9 to re-execute the real-time energy value judgment.

[0475] In S11, the terminal 2400 detects the sustained long-press signal and switches the crosshair indicator to the absorption state (i.e., acquisition in progress). Specifically, when the real-time energy value is greater than a first energy threshold and the target entity is within the selected range, the input acquisition unit 2404 can detect the press signal executed by the user on the acquisition operation key, such as the left mouse button press signal, the SPACE button press signal, the touch press signal, or the gamepad button press signal. The processor 2401 can record the button or touch press moment and continuously monitor the press state. If the press duration is less than the duration threshold, it can be determined that the press operation is a second press operation. At this time, the processor 2401 can control the display unit 2403 to display a third prompt message to prompt the user that a long press is required to perform continuous acquisition. As an implementation method, the processor 2401 can also execute progressive guidance logic, that is, control the acquisition progress bar corresponding to the target entity to quickly increase to about 25% and stop after a spring rebound effect, thereby implying that the user needs to maintain the long press operation. If the pressing duration is greater than or equal to a preset duration threshold, and the user continues to press, then the pressing operation can be determined as a valid acquisition trigger operation. At this time, the processor 2401 controls the crosshair indicator to switch from the aimed state to the absorption state. The absorption state can be regarded as a specific manifestation of the acquisition in progress state, and then enters S12.

[0476] In S12, the terminal 2400 deducts energy values ​​according to the energy value decay rate as the continuous acquisition progresses, and updates the energy progress bar and particle effects. Specifically, during the playback of the animation of continuous acquisition of the target entity, the energy value decay calculation unit 2406 can perform energy value deduction calculations according to the preset energy value decay rate and frame time interval. The relevant details can be found in the aforementioned formula and will not be repeated here. After each frame calculation, the energy value decay calculation unit 2406 can write the updated real-time energy value into the memory 2402; the processor 2401 can send an energy progress bar update instruction to the display unit 2403 to update the fill length of the energy progress bar; the processor 2401 can also calculate the energy ratio R (i.e., the ratio of the real-time energy value to the target energy upper limit value). If the energy ratio R is less than or equal to 0.2 and the current state is not fatigued, the energy progress bar is switched to a fatigued state; if the real-time energy value is less than or equal to the first energy threshold, a lock state switch is triggered, and continuous acquisition is paused. Simultaneously, the graphics processing unit 2405 can render continuous acquisition animations, such as the target entity being pulled towards the crosshair indicator, particle effects flowing from the target entity towards the crosshair, animations of the target entity gradually shrinking or disappearing, and the increasing animation of a 3D progress bar or circular progress bar on the target entity. Thus, the user can simultaneously perceive the continuous acquisition progress and energy consumption process of the target entity.

[0477] In S13, the terminal 2400 determines whether the long press operation continues. Specifically, during the execution of S12, the processor 2401 can continuously monitor the press state collected by the input acquisition unit 2404. If the user continues to hold the long press and the continuous acquisition progress of the target entity has not yet reached the acquisition completion stage, S12 continues to be executed, causing the energy value decay calculation unit 2406 to continue deducting the real-time energy value, and causing the graphics processing unit 2405 to continue rendering the continuous acquisition animation and particle effects. If the user releases the long press signal, such as releasing the left mouse button, releasing the SPACE key, or stopping the touch press, it indicates that an acquisition pause operation has occurred, and the process proceeds to S14. If the user holds the long press until the acquisition progress of the target entity reaches 100%, that is, the target entity is completely acquired, the process proceeds to S15.

[0478] In S14, the terminal 2400 performs a release and unhooking process, interrupting continuous acquisition while retaining the progress of continuous acquisition. Specifically, in response to the release signal acquired by the input acquisition unit 2404, the processor 2401 controls the energy value decay calculation unit 2406 to stop deducting the real-time energy value and controls the graphics processing unit 2405 to stop or pause particle effect rendering. The processor 2401 can also write the current acquisition progress value of the target entity into the memory 2402 for retention and restore the crosshair indicator from the absorption state to the aiming state. That is to say, after the user releases the hand, the continuous acquisition progress of the target entity will not be reset; when the user subsequently performs a valid long press operation on the same target entity again, continuous acquisition can continue based on the progress retained in the memory 2402. Thus, a flexible interactive process of interruption, progress retention, and resumption of acquisition can be formed.

[0479] In S15, the virtual resource acquisition of the target entity is completed, and the collection progress of the reward resources is updated (e.g., the reward progress parameter is accumulated). Specifically, when the processor 2401 determines that the continuous acquisition progress of the target entity has reached the acquisition completion stage, it can mark the target entity as acquired and control the graphics processing unit 2405 to render the disappearance animation, absorption animation, or acquisition completion animation of the target entity in the first virtual scene interface. The processor 2401 can also send the acquisition result data packet to the server 2410 via the communication module 2407 through the communication network 2420. The acquisition result data packet may include the target entity identifier, resource type, resource quantity, quality level, etc. After the service communication module 2417 of the server 2410 receives the acquisition result data packet, the service processor 2411 can call the resource output control unit 2416 to determine the virtual resources corresponding to the target entity and call the reward progress management module 2414 to accumulate the virtual resources acquired this time to the corresponding reward progress parameter. Thus, when the continuous acquisition of the target entity is completed, the terminal 2400 acquires the virtual resources corresponding to the target entity, and the reward progress on the server 2410 side is updated synchronously.

[0480] In S16, terminal 2400 renders a pop-up notification. Specifically, processor 2401 can generate display data for a second notification based on the resource information of the virtual resource corresponding to the target entity. The second notification can be displayed in the first virtual scene interface as a pop-up notification to indicate the resource information of the acquired virtual resource. As one implementation, processor 2401 can select the corresponding rendering parameters from a preset pop-up style mapping table based on the quality attributes of the acquired resource. If the acquired resource is a normal resource, a normal pop-up style can be selected; if the acquired resource is a high-rarity resource or a special resource acquired for the first time, a special pop-up style can be selected. The special pop-up style may include an item icon, a quality border, a special font color, or other highlighting effects. Display unit 2403 can display the second notification in a designated area of ​​the first virtual scene interface and set a preset display duration, such as 2 seconds. After the second notification has been displayed for the preset duration, processor 2401 can control the second notification to move along a preset direction until it disappears from the first virtual scene interface. If there are multiple virtual resources produced simultaneously, or multiple target entities complete collection in a short period of time, resulting in multiple second prompt messages, the processor 2401 can trigger multiple second prompt messages sequentially at a preset time interval, such as popping up a second prompt message every 100 milliseconds, to reduce the obstruction caused by multiple prompt messages being displayed simultaneously.

[0481] In S17, terminal 2400 determines whether the collection progress of reward resources has reached the target progress. Specifically, processor 2401 can query the current reward progress parameters from server 2410 via communication network 2420 through communication module 2407. Server 2410's reward progress management module 2414 can read the current reward progress parameters and return them to terminal 2400 via service communication module 2417. Processor 2401 can compare the current reward progress parameters with the target progress or multiple tier thresholds. If the current reward progress parameters have not reached the target progress or any available tier threshold, it can return to S4, continue responding to the user's view control operations, and enter the next round of aiming, target entity hit judgment, and continuous collection. If the current reward progress parameters have reached the target progress or a certain tier threshold, processor 2401 can update the available status flag of the reward collection module and enter S18.

[0482] In S18, terminal 2400 renders the reward claiming interface and displays a "Congratulations on receiving" pop-up. Specifically, when the reward resource's claimable status flag indicates that the reward resource is available for claiming, the user can trigger a claiming operation for the reward resource. Input acquisition unit 2404 can acquire this claiming operation and transmit it to processor 2401. Processor 2401 can send a reward claiming request to server 2410 via communication module 2407 through communication network 2420. After receiving the reward claiming request, server 2410's service communication module 2417 can call reward progress management module 2414 and resource output control unit 2416 to determine the available reward resources and return the reward resource information to terminal 2400 via service communication module 2417. Display unit 2403 can display the reward claiming interface based on the returned reward resource information and display a claiming success prompt, such as a "Congratulations on receiving" pop-up. This "Congratulations on receiving" pop-up may include at least one of the following: claiming success prompt, reward resource icon, reward resource name, reward resource quantity, and reward list.

[0483] In S19, the terminal 2400 restores the energy value through a background energy value automatic recovery timer. Specifically, the processor 2401 can start the background energy value automatic recovery timer when initializing the energy value parameters in S3. This background energy value automatic recovery timer can control the energy value attenuation calculation unit 2406 to increase and restore the real-time energy value according to a preset recovery rate and a fixed recovery time interval during non-continuous acquisition. The restored real-time energy value is then written to the memory 2402. This background energy value automatic recovery timer can be paused when the user is performing continuous acquisition, i.e., during the execution of S12, to avoid simultaneous energy value deduction and recovery; it can continue to run in other states, such as the unaimed state, the aimed state, the locked state, and the paused state after release. If the real-time energy value recovers from less than or equal to the first energy threshold to greater than the first energy threshold, the processor 2401 can automatically unlock the state, restore the crosshair indicator to the usable state, switch the acquisition operation key identifier from the disabled state to the usable state, and then return to S9 to re-execute the real-time energy value judgment.

[0484] In S20, the process ends. Specifically, after completing the continuous acquisition of the target entity, judging the reward progress, or claiming the reward, if the user remains in the resource acquisition mode, the terminal 2400 can return to S4 to continue responding to the user's perspective control operations and perform the next round of target entity selection and continuous acquisition. If the user performs an exit operation, such as pressing the ESC key, clicking the exit control, or performing a return operation, the input acquisition unit 2404 can acquire the exit signal and transmit the exit signal to the processor 2401. In response to the exit signal, the processor 2401 can control the display unit 2403 to restore the head-up display interface elements that were hidden before entering the resource acquisition mode, and switch the virtual camera from the first-person perspective mode back to the third-person perspective mode. The processor 2401 can also clear the resource acquisition mode-related interface elements in the first virtual scene interface, such as the crosshair indicator, energy progress bar, acquisition operation key labels, hover information bubbles, and second prompt information. The processor 2401 can also persist data such as the current real-time energy value, the continuous acquisition progress of the target entity, and the collection progress of reward resources to the memory 2402, or synchronize it to the service memory 2412 of the server 2410 via the communication module 2407. If there are unclaimed reward resources when exiting the resource acquisition mode, the processor 2401 can also display a prompt message in the header display of the normal virtual scene interface or the home interface to remind the user that there are rewards to claim. Thus, the terminal 2400 can complete the exit from the resource acquisition mode and end the current virtual resource acquisition process.

[0485] It should be noted that, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0486] Based on the virtual resource acquisition method provided in the foregoing embodiments, this application also provides a virtual resource acquisition device. See also... Figure 26 As shown, the virtual resource acquisition device 2600 includes a display unit 2601, a playback unit 2602, a deduction unit 2603, and an acquisition unit 2604;

[0487] The display unit 2601 is used to display a first virtual scene interface in resource acquisition mode, the first virtual scene interface including an initial energy value and an entity to be acquired;

[0488] The playback unit 2602 is used to play an animation of continuous acquisition of the target entity in response to the acquisition trigger operation if the target entity in the entity to be acquired is within the selected range and the initial energy value is greater than the first energy threshold.

[0489] The deduction unit 2603 is used to deduct the initial energy value to obtain a real-time energy value as the continuous acquisition progresses during the playback of the animation of continuous acquisition of the target entity, and when the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the continuous acquisition progress is acquisition completion.

[0490] The acquisition unit 2604 is used to acquire the virtual resources corresponding to the target entity when the progress of the continuous acquisition is completed.

[0491] Optionally, the deduction unit 2603 is specifically used for:

[0492] As the continuous data acquisition progresses, the initial energy value is subtracted to obtain the real-time energy value, and the visual status of the real-time energy value is displayed.

[0493] Optionally, the deduction unit 2603 is specifically used for:

[0494] If the real-time energy value is greater than the first energy threshold and less than the second energy threshold, the visual state of the real-time energy value is a fatigue state, and the second energy threshold is greater than the first energy threshold.

[0495] If the real-time energy value is greater than or equal to the second energy threshold, the visual state displaying the real-time energy value is normal.

[0496] Optionally, the device further includes a locking state unit for:

[0497] If the real-time energy value is less than or equal to the first energy threshold, the visual state of the real-time energy value is locked, and the continuous acquisition is paused, while the progress of the continuous acquisition at the current moment is retained.

[0498] The real-time energy value is restored.

[0499] When the real-time energy value recovers to a level greater than the first energy threshold, the locking state of the real-time energy value is released, and the continuous acquisition is resumed based on the retained progress of the continuous acquisition.

[0500] Optionally, the initial energy value is represented by an energy progress bar, the outer frame of the energy progress bar represents the target energy upper limit, and the fill length of the energy progress bar represents the initial energy value. The deduction unit 2603 is specifically used for:

[0501] As the continuous data acquisition progresses, the fill length of the energy progress bar decreases, resulting in a real-time fill length, which represents the real-time energy value.

[0502] Optionally, the energy progress bar includes a native segment progress bar and an extended segment progress bar, the target energy upper limit value includes a native energy upper limit value and an extended energy upper limit value, the progress bar outline of the native segment progress bar represents the native energy upper limit value, and the progress bar outline of the extended segment progress bar represents the extended energy upper limit value.

[0503] Optionally, the first virtual scene interface further includes a crosshair indicator, and the playback unit 2602 is specifically used for:

[0504] If the crosshair indicator hits the target entity, then the target entity is within the selected range.

[0505] Optionally, if the crosshair indicator hits the target entity and the target entity is within the selected range, the device further includes a first state switching unit, used for:

[0506] Switch the crosshair indicator from the unaimed state to the aimed state.

[0507] Optionally, the playback unit 2602 is specifically used for:

[0508] In response to the acquisition trigger operation, the crosshair indicator is displayed as acquisition in progress, and an animation of continuous acquisition of the target entity is played. The acquisition in progress status is used to reflect the progress of the continuous acquisition.

[0509] Optionally, the device further includes a second state switching unit, used for:

[0510] If the real-time energy value is less than or equal to the first energy threshold, the continuous acquisition is paused, and the state displayed on the crosshair indicator is switched from the acquisition in progress state to the locked state.

[0511] The real-time energy value is restored.

[0512] When the real-time energy value recovers to a level greater than the first energy threshold, the state displayed by the crosshair indicator is switched from the locked state to the acquisition in progress state.

[0513] Optionally, the device further includes a third state switching unit, used for:

[0514] If, in response to a data acquisition pause operation, the continuous data acquisition is paused, the state displayed on the crosshair indicator is switched from the data acquisition in progress state to the aiming state;

[0515] When the acquisition trigger operation is executed again, the animation of continuous acquisition of the target entity continues to play, and the state displayed by the crosshair indicator is switched from the aimed state to the acquisition in progress state.

[0516] Optionally, the device further includes a first prompting unit, used for:

[0517] If the target entity is within the selected range and the initial energy value is less than or equal to the first energy threshold, in response to the acquisition trigger operation, a first prompt message is displayed and the crosshair indicator is displayed in a locked state. The first prompt message is used to indicate that the initial energy value is insufficient.

[0518] Optionally, the device further includes a progress saving unit for:

[0519] During the playback of the animation of continuous acquisition of the target entity, in response to the acquisition pause operation, the continuous acquisition is paused, while the real-time energy value and the progress of the continuous acquisition at the current moment are retained.

[0520] During the pause of the continuous data acquisition, the energy value is restored based on the real-time energy value at the current moment;

[0521] When the acquisition trigger operation is re-executed, the animation of continuous acquisition of the target entity continues to play. The real-time energy value after the energy value is increased is used as the initial energy value. The process of subtracting the initial energy value from the real-time energy value as the progress of the continuous acquisition continues to be executed. When the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the progress of the continuous acquisition is the acquisition completion step.

[0522] Optionally, after the target entity in the entity to be acquired is within the selected range, the device further includes an entity information display unit, used for:

[0523] If the rarity of the target entity is higher than the rarity threshold, the entity information of the target entity is displayed in the first virtual scene interface.

[0524] Optionally, the entity information display unit is specifically used for:

[0525] Based on the quality level of the target entity, display the entity information of the target entity in a display appearance corresponding to the quality level.

[0526] Optionally, the device further includes a second prompting unit for:

[0527] When the continuous data collection progresses to completion, a second prompt message is displayed in the first virtual scene interface. The second prompt message is used to indicate the resource information of the acquired virtual resource.

[0528] Optionally, the second prompting unit is specifically used for:

[0529] Display a second prompt message for a preset duration on the first virtual scene interface;

[0530] After the preset duration of the second prompt message is displayed, the second prompt message is controlled to disappear from the first virtual scene interface.

[0531] Optionally, if there are multiple second prompt messages, each second prompt message is a second prompt message indicating that a virtual resource corresponding to a single target entity has been obtained, and the second prompt unit is specifically used for:

[0532] According to a preset time interval, each of the second prompt messages is displayed sequentially in the first virtual scene interface;

[0533] For each of the second prompt messages, after the second prompt message is displayed, the second prompt message is controlled to move along a preset direction in the first virtual scene interface until it disappears from the first virtual scene interface.

[0534] Optionally, the deduction unit 2603 is specifically used for:

[0535] As the continuous acquisition progresses, the initial energy value is subtracted according to the energy value decay rate and frame time interval to obtain the real-time energy value. The energy value decay rate is determined based on at least one of the following: the attributes of the target entity, the distance between the target entity and the virtual resource acquisition device, or the visual state of the real-time energy value.

[0536] Optionally, the display unit 2601 is specifically used for:

[0537] The second virtual scene interface is displayed, which includes the target virtual character and the target capture point;

[0538] If the distance between the target virtual character and the target capture point is less than a distance threshold, a mode switching prompt will be displayed in the second virtual scene interface;

[0539] In response to the mode switching operation, the user enters the first virtual scene interface, and the mode switching operation is performed based on the mode switching prompt.

[0540] Optionally, the display unit 2601 is specifically used for:

[0541] In response to the mode switching operation, the second virtual scene interface, which is in a third-person perspective, is switched to the first virtual scene interface, which is in a first-person perspective.

[0542] This application also provides a computer device capable of executing a method for acquiring virtual resources. This computer device may be a terminal. Figure 27 This diagram illustrates the structure of a terminal according to an embodiment of this application. Figure 27 In this example, taking a smartphone as the terminal:

[0543] refer to Figure 27 The smartphone includes components such as: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a Wi-Fi module 1070, a processor 1080, and a power supply 1090. The input unit 1030 may include a touch panel 1031 and other input devices 1032, the display unit 1040 may include a display panel 1041, and the audio circuit 1060 may include a speaker 1061 and a microphone 1062. It is understood that... Figure 10 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0544] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various functions and applications of the smartphone and accesses virtual resources by running the software programs and modules stored in the memory 1020. The memory 1020 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created based on the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1020 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0545] The processor 1080 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1020 and by accessing data stored in the memory 1020. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1080.

[0546] In this embodiment, the processor 1080 in the smartphone can execute the methods provided in the various embodiments of this application.

[0547] The computer device provided in this application embodiment can also be a server. Please refer to [link / reference]. Figure 28 As shown, Figure 28 The diagram illustrates the structure of a server 1100 provided in this embodiment. The server 1100 can vary significantly due to different configurations or performance characteristics. It may include one or more processors, such as a Central Processing Unit (CPU) 1122, and a memory 1132, as well as one or more storage media 1130 (e.g., one or more mass storage devices) for storing application programs 1142 or data 1144. The memory 1132 and storage media 1130 may be temporary or persistent storage. The program stored in the storage media 1130 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1122 may be configured to communicate with the storage media 1130 and execute the series of instruction operations stored in the storage media 1130 on the server 1100.

[0548] Server 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input / output interfaces 1158, and / or one or more operating systems 1141, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0549] In this embodiment, the central processing unit 1122 in the server 1100 can execute the methods provided in the various embodiments of this application.

[0550] According to one aspect of this application, a computer-readable storage medium is provided for storing a computer program for performing the methods described in the foregoing embodiments.

[0551] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in various optional implementations of the above embodiments.

[0552] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

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

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

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

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

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

[0558] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0559] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for acquiring virtual resources, characterized in that, The method includes: The first virtual scene interface, which is in resource acquisition mode, is displayed. The first virtual scene interface includes the initial energy value and the entity to be acquired. If the target entity in the entity to be acquired is within the selected range, and the initial energy value is greater than the first energy threshold, in response to the acquisition trigger operation, an animation of continuous acquisition of the target entity is played; During the playback of the animation of continuous acquisition of the target entity, the initial energy value is subtracted to obtain a real-time energy value as the continuous acquisition progresses, and the continuous acquisition continues to be executed until the continuous acquisition progress is completed when the real-time energy value is greater than the first energy threshold. When the continuous data collection is completed, the virtual resources corresponding to the target entity are acquired.

2. The method according to claim 1, characterized in that, The step of subtracting the initial energy value to obtain the real-time energy value as the continuous data acquisition progresses includes: As the continuous data acquisition progresses, the initial energy value is subtracted to obtain the real-time energy value, and the visual status of the real-time energy value is displayed.

3. The method according to claim 2, characterized in that, The visual state displaying the real-time energy value includes: If the real-time energy value is greater than the first energy threshold and less than the second energy threshold, the visual state of the real-time energy value is a fatigue state, and the second energy threshold is greater than the first energy threshold. If the real-time energy value is greater than or equal to the second energy threshold, the visual state displaying the real-time energy value is normal.

4. The method according to claim 3, characterized in that, The method further includes: If the real-time energy value is less than or equal to the first energy threshold, the visual state of the real-time energy value is locked, and the continuous acquisition is paused, while the progress of the continuous acquisition at the current moment is retained. The real-time energy value is restored. When the real-time energy value recovers to a level greater than the first energy threshold, the locking state of the real-time energy value is released, and the continuous acquisition is resumed based on the retained progress of the continuous acquisition.

5. The method according to claim 1, characterized in that, The initial energy value is represented by an energy progress bar, the outer frame of which represents the target energy upper limit, and the fill length of the energy progress bar represents the initial energy value. The process of subtracting the initial energy value as the continuous data acquisition progresses to obtain the real-time energy value includes: As the continuous data acquisition progresses, the fill length of the energy progress bar decreases, resulting in a real-time fill length, which represents the real-time energy value.

6. The method according to claim 5, characterized in that, The energy progress bar includes a native segment progress bar and an extended segment progress bar. The target energy upper limit includes a native energy upper limit and an extended energy upper limit. The outer frame of the native segment progress bar represents the native energy upper limit, and the outer frame of the extended segment progress bar represents the extended energy upper limit.

7. The method according to claim 1, characterized in that, The first virtual scene interface also includes a crosshair indicator, and the step of "if the target entity in the entity to be acquired is within the selected range" includes: If the crosshair indicator hits the target entity, then the target entity is within the selected range.

8. The method according to claim 7, characterized in that, If the crosshair indicator hits the target entity and the target entity is within the selected range, the method further includes: Switch the crosshair indicator from the unaimed state to the aimed state.

9. The method according to claim 7, characterized in that, The step of playing an animation of continuous data acquisition of the target entity in response to a data acquisition trigger operation includes: In response to the acquisition trigger operation, the crosshair indicator is displayed as acquisition in progress, and an animation of continuous acquisition of the target entity is played. The acquisition in progress status is used to reflect the progress of the continuous acquisition.

10. The method according to claim 9, characterized in that, The method further includes: If the real-time energy value is less than or equal to the first energy threshold, the continuous acquisition is paused, and the state displayed on the crosshair indicator is switched from the acquisition state to the locked state. The real-time energy value is restored. When the real-time energy value recovers to a level greater than the first energy threshold, the state displayed by the crosshair indicator is switched from the locked state to the acquisition in progress state.

11. The method according to claim 9, characterized in that, The method further includes: If, in response to a data acquisition pause operation, the continuous data acquisition is paused, the state displayed on the crosshair indicator is switched from the data acquisition in progress state to the aiming state; When the acquisition trigger operation is executed again, the animation of continuous acquisition of the target entity continues to play, and the state displayed by the crosshair indicator is switched from the aimed state to the acquisition in progress state.

12. The method according to claim 7, characterized in that, The method further includes: If the target entity is within the selected range and the initial energy value is less than or equal to the first energy threshold, in response to the acquisition trigger operation, a first prompt message is displayed and the crosshair indicator is displayed in a locked state. The first prompt message is used to indicate that the initial energy value is insufficient.

13. The method according to claim 1, characterized in that, The method further includes: During the playback of the animation of continuous acquisition of the target entity, in response to the acquisition pause operation, the continuous acquisition is paused, while the real-time energy value and the progress of the continuous acquisition at the current moment are retained. During the pause of the continuous data acquisition, the energy value is restored based on the real-time energy value at the current moment; When the acquisition trigger operation is re-executed, the animation of continuous acquisition of the target entity continues to play. The real-time energy value after the energy value is increased is used as the initial energy value. The process of subtracting the initial energy value from the real-time energy value as the progress of the continuous acquisition continues to be executed. When the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the progress of the continuous acquisition is the acquisition completion step.

14. The method according to claim 1, characterized in that, After the statement that the target entity in the entity to be acquired is within the selected range is mentioned, the method further includes: If the rarity of the target entity is higher than the rarity threshold, the entity information of the target entity is displayed in the first virtual scene interface.

15. The method according to claim 14, characterized in that, The step of displaying the entity information of the target entity in the first virtual scene interface includes: Based on the quality level of the target entity, display the entity information of the target entity in a display appearance corresponding to the quality level.

16. The method according to claim 1, characterized in that, The method further includes: When the continuous data collection progresses to completion, a second prompt message is displayed in the first virtual scene interface. The second prompt message is used to indicate the resource information of the acquired virtual resource.

17. The method according to claim 16, characterized in that, The step of displaying the second prompt information in the first virtual scene interface includes: Display a second prompt message for a preset duration on the first virtual scene interface; After the preset duration of the second prompt message is displayed, the second prompt message is controlled to disappear from the first virtual scene interface.

18. The method according to claim 16, characterized in that, If there are multiple second prompt messages, and each second prompt message is a prompt message indicating that a virtual resource corresponding to a single target entity has been obtained, then displaying the second prompt message in the first virtual scene interface includes: According to a preset time interval, each of the second prompt messages is displayed sequentially in the first virtual scene interface; For each of the second prompt messages, after the second prompt message is displayed, the second prompt message is controlled to move along a preset direction in the first virtual scene interface until it disappears from the first virtual scene interface.

19. The method according to any one of claims 1-18, characterized in that, The step of subtracting the initial energy value to obtain the real-time energy value as the continuous data acquisition progresses includes: As the continuous acquisition progresses, the initial energy value is subtracted according to the energy value decay rate and frame time interval to obtain the real-time energy value. The energy value decay rate is determined based on at least one of the following: the attributes of the target entity, the distance between the target entity and the virtual resource acquisition device, or the visual state of the real-time energy value.

20. The method according to any one of claims 1-18, characterized in that, The first virtual scene interface, which is displayed in resource acquisition mode, includes: The second virtual scene interface is displayed, which includes the target virtual character and the target capture point; If the distance between the target virtual character and the target capture point is less than a distance threshold, a mode switching prompt will be displayed in the second virtual scene interface; In response to the mode switching operation, the user enters the first virtual scene interface, the mode switching operation being performed based on the mode switching prompt.

21. The method according to claim 20, characterized in that, The step of entering the first virtual scene interface in response to the mode switching operation includes: In response to the mode switching operation, the second virtual scene interface, which is in a third-person perspective, is switched to the first virtual scene interface, which is in a first-person perspective.

22. A device for acquiring virtual resources, characterized in that, The device includes a display unit, a playback unit, a deduction unit, and an acquisition unit; The display unit is used to display a first virtual scene interface in resource acquisition mode, the first virtual scene interface including an initial energy value and an entity to be acquired; The playback unit is configured to play an animation of continuous acquisition of the target entity in response to a acquisition trigger operation if the target entity in the entity to be acquired is within the selected range and the initial energy value is greater than the first energy threshold. The deduction unit is used to subtract the initial energy value to obtain a real-time energy value as the continuous acquisition progresses during the playback of the animation of performing continuous acquisition on the target entity, and when the real-time energy value is greater than the first energy threshold, the continuous acquisition continues to be executed until the continuous acquisition progress is acquisition completion. The acquisition unit is used to acquire the virtual resources corresponding to the target entity when the progress of the continuous acquisition is completed.

23. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the method according to any one of claims 1-21 according to instructions in the computer program.

24. A computer-readable storage medium for storing a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-21.

25. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1-21.

Images