An information processing method, an electronic device, and a computer-readable storage medium

Abstract

An embodiment of the present application provides an information processing method, comprising: displaying a virtual production object in a graphical user interface; in response to a first operation on the virtual production object, generating an initial path point according to a first position corresponding to the first operation, the first operation comprising a basic trigger action; in response to a second operation on the virtual production object, generating a second path point according to a second position corresponding to the second operation, and generating an ordered path node queue according to the initial path point and the second path point, the second operation comprising the basic trigger action and an auxiliary trigger action cooperating with the basic trigger action; and in response to the virtual production object producing a first virtual object, controlling the first virtual object to move in order according to nodes in the ordered path node queue.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an information processing method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In related technologies, virtual production objects within a virtual scene typically have path configuration capabilities. After a user selects a virtual production object, they can specify a target location within the virtual scene, and the system sets that location as a path point for that virtual production object. Virtual objects produced by that virtual production object will then automatically move to that path point and wait for further instructions.

[0003] However, the relevant technologies only support configuring a single target location and cannot pre-plan ordered movement paths containing multiple nodes. When a user expects a virtual object to complete multiple steps, they must wait for each step to complete and manually issue the next movement command. This frequent manual interaction is not only cumbersome but also easily leads to command redundancy in the terminal due to receiving a large number of discrete movement commands, increasing the terminal's data processing pressure. Summary of the Invention

[0004] This application provides an information processing method, an electronic device, and a computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this application, an information processing method is provided, the method comprising: displaying a virtual production object in a graphical user interface; in response to a first operation on the virtual production object, generating an initial path point according to a first position corresponding to the first operation, the first operation including a basic triggering action; in response to a second operation on the virtual production object, generating a second path point according to a second position corresponding to the second operation, and generating an ordered path node queue according to the initial path point and the second path point, the second operation including a basic triggering action and an auxiliary triggering action in conjunction with the basic triggering action; and in response to the virtual production object producing a first virtual object, controlling the first virtual object to move sequentially according to the node order in the ordered path node queue.

[0006] According to one aspect of this application, an electronic device is provided, comprising: a processor, a memory, and computer program instructions stored in the memory and executable on the processor; the processor, when executing the computer program instructions, implements any of the above-described information processing methods.

[0007] According to one aspect of this application, a computer-readable storage medium is provided, which stores computer program instructions that, when executed by a processor, are used to implement any of the information processing methods described above.

[0008] One embodiment of this application provides an information processing method, including: displaying a virtual production object in a graphical user interface; generating an initial path point based on a first position corresponding to a first operation on the virtual production object, the first operation including a basic triggering action; generating a second path point based on a second position corresponding to a second operation on the virtual production object, and generating an ordered path node queue based on the initial path point and the second path point, the second operation including a basic triggering action and an auxiliary triggering action in conjunction with the basic triggering action; and controlling the first virtual object to move sequentially according to the node order in the ordered path node queue in response to the virtual production object producing a first virtual object. By generating an initial path point in response to a first operation including a basic triggering action, and generating a second path point and an ordered path node queue in response to a second operation including a basic triggering action and an auxiliary triggering action, the generated virtual object is controlled to move sequentially according to the node order in the queue, reducing the number of times the user manually issues movement commands, helping to reduce the instruction processing overhead of the terminal, and improving the scheduling efficiency of virtual objects. Attached Figure Description

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

[0010] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this application. Figure 2 This application shows a flowchart of a method in one exemplary embodiment; Figure 3 A schematic diagram of a graphical user interface in one exemplary embodiment of this application is shown; Figure 4 A schematic diagram of a graphical user interface in one exemplary embodiment of this application is shown; Figure 5 This illustration shows a schematic diagram of the structure of an electronic device according to one exemplary embodiment of the present application. Detailed Implementation

[0011] Exemplary embodiments of this application will be described more fully below with reference to the accompanying drawings.

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, 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 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.

[0014] The accompanying drawings are schematic illustrations of this application and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this application can be combined in any suitable manner in one or more implementations. In the following description, numerous specific details are provided to give a thorough description of the embodiments of this application. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this application, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0015] Figure 1A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a graphical user interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing the game service in this exemplary embodiment; it may be a single server or a cluster of multiple servers. For example, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this application can be executed by any one or more of the terminal device 110 and the server 120.

[0016] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0017] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0018] Information processing method according to one embodiment of this application, such as Figure 2 As shown, the method may include: Step S210: Display the virtual production object in the graphical user interface; Step S230: In response to a first operation on a virtual production object, an initial path point is generated based on the first position corresponding to the first operation. The first operation includes a basic triggering action. Step S250: In response to the second operation for the virtual production object, a second path point is generated according to the second position corresponding to the second operation, and an ordered path node queue is generated according to the initial path point and the second path point. The second operation includes a basic triggering action and an auxiliary triggering action that cooperates with the basic triggering action. Step S270: In response to the virtual production object producing the first virtual object, control the first virtual object to move sequentially according to the node order in the ordered path node queue.

[0019] According to one embodiment of this application, an initial path point is generated in response to a first operation including a basic triggering action, and a second path point and an ordered path node queue are generated in response to a second operation including a basic triggering action and an auxiliary triggering action. This controls the generated virtual objects to move sequentially according to the node order in the queue, reducing the number of times the user manually issues movement commands, helping to reduce the instruction processing overhead of the terminal, and improving the scheduling efficiency of virtual objects.

[0020] The embodiments of this application will be further described below.

[0021] In step S210, a virtual production object is displayed in the graphical user interface.

[0022] By displaying virtual production objects in the graphical user interface, players are provided with an intuitive and visual building identification interface, which makes it easy for players to quickly locate and select target production buildings to perform subsequent rally path configuration operations.

[0023] Optionally, the virtual production object can be a building object used in strategy games to produce virtual units, which is displayed in the graphical user interface for players to select and configure the rally path.

[0024] Optionally, virtual production objects can be various different types of production buildings, such as Figure 3As shown, the battlefield map presented in the graphical user interface 300 contains multiple virtual production objects 310 of different types, such as barracks for training infantry, stables for producing cavalry, or armories for manufacturing mechanical units. The virtual production objects in the graphical user interface can be displayed as 3D building models, 2D icons, or simplified markers, and their display positions correspond to their actual construction locations on the game map. It should be noted that, in addition to displaying the building's appearance, virtual production objects can also display current production status information, such as the type of unit being produced or a production progress bar, so that players can understand its operational status before selecting the building. Furthermore, when the mouse cursor hovers over a virtual production object, the interface can further display a summary of the building's configured rally paths. The above description of the specific types and display forms of virtual production objects is only an illustrative example; in actual implementation, it can be flexibly determined according to game design requirements.

[0025] In step S230, in response to a first operation on a virtual production object, an initial path point is generated based on a first position corresponding to the first operation. The first operation includes a basic triggering action.

[0026] Initial waypoints can be quickly established through basic trigger actions, providing a foundation for subsequent multi-node path configuration. The operation is intuitive and in line with player habits, reducing the learning cost of configuring complex paths.

[0027] Optionally, the first operation is used to establish or reset the starting point of the assembly path for virtual production objects.

[0028] Optionally, the first operation can be a direct interactive command to a virtual production object, which can take the form of a mouse click, touch click, or gesture swipe. Considering that players need to respond quickly in a large-scale battlefield environment, the first operation is usually designed as a low-latency, single input action. In one specific approach, the first operation is a right-click operation. The system listens for this input event and obtains the world coordinates corresponding to the operation as the first position. It should be noted that the above description of the specific input form of the first operation is only one example. This application does not intend to limit the triggering method of this operation. In actual implementation, it can be flexibly adjusted according to the hardware configuration or input interface of the terminal device. For example, on a gamepad, it can be mapped to a combination of pressing specific function keys.

[0029] Optionally, besides constituting the first operation through a direct click, the first operation can also include a series of logically related sub-actions. To prevent players from accidentally setting incorrect initial waypoints in complex terrain, the aforementioned first operation can also be combined with a foolproof mechanism. For example, when the system detects that the first position corresponding to the first operation is in an unreachable area, it can refuse to generate an initial waypoint and display a prompt message in the graphical user interface, or automatically correct the first position to the nearest reachable boundary point to the unreachable area. One objective of this embodiment is that by combining the first operation with boundary verification logic, on the one hand, the generated initial waypoints can be ensured to be valid, and on the other hand, the time cost of repeated trial and error for players can be reduced, improving the smoothness of deployment planning.

[0030] Optionally, the first position indicates the initial assembly coordinates or area corresponding to the virtual production object in the virtual environment. Optionally, the first position can be an absolute coordinate point in the virtual environment or a relative offset position relative to the virtual production object. In the graphical user interface, the first position is typically mapped to a specific landing point specified by the player on the game map via an input device. This landing point can be located in different terrain areas such as open plains, near resource points, or strategic routes. It should be noted that the first position is not limited to a precise pixel-level coordinate; it can also be the center of a circular area with a certain radius. When the first position is set as a region, subsequently produced virtual objects reaching the edge of this region are considered to have arrived at the initial pathpoint. This regionalized position definition effectively addresses the problem of crowded positions caused by differences in the size of virtual objects, improving space utilization during multi-unit assembly.

[0031] Optionally, the initial path point is used as the starting node of an ordered queue of path nodes or the current unique node.

[0032] Optionally, the initial waypoint can be the first node in an ordered queue of path nodes, or, under specific circumstances, a single node in the queue. When the virtual production object does not currently have an existing queue of path nodes, the generation of the initial waypoint signifies the establishment of a new queue; when an existing queue exists, the generation of the initial waypoint means the clearing of the old queue and the overwriting of the new queue. Visually, the initial waypoint is usually accompanied by a specific interface marker, such as a circular flag icon with an ordered number. Considering that players may need to quickly switch deployment strategies for different buildings, the generation process of the initial waypoint should be instantaneous and without delay. Furthermore, the initial waypoint not only records spatial coordinate information but can also include extended attributes such as the node's dwell time and formation requirements. These attributes can further enrich the unit's deployment behavior, transforming simple movement commands into garrison commands with tactical intent.

[0033] Optionally, the basic trigger action is used as the basic input signal for generating the trigger path point, which is different from the auxiliary trigger action.

[0034] Optionally, the basic trigger action can be a single input behavior independent of the auxiliary trigger action, and its input type can include various forms such as key input, touch input, or voice input. In one embodiment, the basic trigger action is specifically manifested as a click operation on a target location, such as pressing and releasing the right mouse button. The function of this basic trigger action is to convey the intention to overwrite or reset to the system, that is, to clear the historical path configuration and replan the path starting from the current input position. It should be noted that the triggering timing and duration of the basic trigger action can be set according to the interaction requirements. For example, it can be set to take effect after a long press reaches a preset time threshold to avoid accidental triggering during rapid multi-point operations. This application does not limit the specific physical form of the basic trigger action, as long as it can be recognized by the system as an independent reset signal.

[0035] Optionally, in addition to triggering basic actions through physical peripheral presses, basic actions can also be implemented through virtual controls in the graphical user interface. To avoid the inability to accurately distinguish between overriding and appending intentions when there are no modifier buttons on gamepads or touchscreens, basic actions can be mapped to button clicks on specific function panels in the interface. For example, when a player selects a virtual production object, a virtual button for resetting the assembly appears at the edge of the interface. Touching this button is the basic action, and the click location on the map will then be determined as the initial waypoint. Similarly, if a player executes a basic action without selecting any building, the system can ignore the input or prompt the player to select a target building first to ensure the contextual validity of the basic action.

[0036] In one specific implementation, such as Figure 3 As shown, after the player selects the virtual production object 310 on the map, they can right-click at any reachable location on the map. Upon receiving this operation, the system uses the clicked location as the initial path point 301 and instantly generates a single dashed line from the virtual production object 310 to the initial path point 301 in the game view, thus completing the single-point configuration.

[0037] In another specific implementation, initial path points can also be set for multiple virtual production objects. For example... Figure 4As shown, after the player selects virtual production object 410 on the map, they right-click at any reachable location on the map. Upon receiving this operation, the system uses the clicked location as the initial pathpoint 401 and instantly generates a single-segment dashed line from virtual production object 410 to the initial pathpoint 401 in the game view, completing the single-point configuration for virtual production object 410. Then, the player selects virtual production object 420 on the map and right-clicks at the location of the initial pathpoint 401 of virtual production object 410. Upon receiving this operation, the system uses the clicked location as the initial pathpoint for virtual production object 420 and instantly generates a single-segment dashed line from virtual production object 420 to the initial pathpoint 401 in the game view, completing the single-point configuration for virtual production object 420.

[0038] In an optional implementation, in response to a first operation on a virtual production object, generating an initial path point based on a first position corresponding to the first operation includes: in response to a first operation on a virtual production object, if the virtual production object already has an existing path node queue, clearing the existing path node queue; and using the first position as the initial path point.

[0039] By performing a clearing operation when an existing path node queue is detected, players can quickly erase complex old path configurations and re-establish initial path points, avoiding interference from historical node remnants on new deployment intentions and improving the flexibility and efficiency of path resetting.

[0040] In one implementation, a player selects a barracks (virtual production object) on the map. This barracks has previously been configured with an existing path node queue containing three nodes. When the player wishes to change the deployment strategy and directly right-clicks on another new frontline location on the map (the first operation), the system detects that the barracks currently has an existing path node queue. It then clears all three historical node records in the queue in the background and uses the newly right-clicked frontline location as the unique initial path point, thus completing the path overwrite and reset.

[0041] Optionally, an existing path node queue is used to record at least one node data from historical configurations. This queue is stored in the background and bound to the virtual production object. Alternatively, the existing path node queue can be an ordered data set accumulated by the virtual production object through multiple interactive operations, containing at least one historical path node with a chronological order. Considering that players need to frequently adjust their deployment strategies when the battlefield situation changes, directly adding new nodes without clearing the old queue would result in lengthy paths and contradict the player's reset intentions. Therefore, as a possible implementation, when the system receives the first operation, it triggers a full clearing mechanism for the existing path node queue. Specifically, the system can traverse the queue's data structure, destroying or marking all historical node coordinates and sequence numbers stored within it as invalid, thereby ensuring that subsequently generated initial path points can serve as single nodes in the queue. It should be noted that the above clearing operation is not limited to data-level deletion; it can also simultaneously trigger the immediate hiding and destruction of old path connections and node markers in the graphical user interface to ensure consistency between visual feedback and underlying data, avoiding cognitive confusion for players.

[0042] Optionally, in addition to performing a full clear upon receiving the first operation, the clearing logic for the existing path node queue can also be designed in conjunction with a specific anti-accidental touch mechanism. To prevent players from accidentally clearing carefully configured long paths due to accidental clicks, when the system detects the first operation and the number of nodes in the current path node queue exceeds a preset threshold (e.g., 3), a secondary confirmation pop-up can be generated in the graphical user interface. After the player confirms, the clearing is performed, and the first position is used as the initial path point. If the player cancels the confirmation, the original queue remains unchanged. Furthermore, this clearing and resetting mechanism forms an orthogonal interactive semantic with subsequent append and extension operations: the first operation represents the intent of "overwrite and reset," while the second operation with auxiliary triggering action represents the intent of "append and extend," and the two do not interfere with each other. This design allows players to flexibly switch between path reconstruction and extension modes through different operation combinations without relying on additional interface buttons, greatly enriching the scheduling and management dimensions of production buildings.

[0043] In an optional implementation, in response to a first operation on a virtual production object, an initial path point is generated based on a first position corresponding to the first operation, including: in response to the first operation on the virtual production object, if the virtual production object currently does not have an existing path node queue; using the first position as the initial path point. This avoids redundant calculations caused by the system performing invalid clearing operations on empty queues, improves the system response efficiency during initial path configuration, and ensures the immediacy and smoothness of initial path point generation.

[0044] In one implementation, when a player selects a newly built barracks for the first time, the system detects that there is currently no existing path node queue for that barracks. At this point, if the player right-clicks on the map, the system directly uses the clicked location as the initial waypoint, without needing to clear any old queues, thus quickly setting the initial waypoint.

[0045] Optionally, considering that players typically configure no rally paths for a newly built production building at the beginning of the game or when configuring the initial path, the system can avoid redundant calculations due to invalid clearing logic on empty queues. As a possible implementation, upon receiving the first operation, the system will first query the path data structure bound to the virtual production object. If the query result is empty or returns an uninitialized flag, it is determined that there is no existing path node queue. In this case, the system skips the queue clearing step and instantiates the first position corresponding to the first operation as the initial path point and writes it into the data structure. It should be noted that determining the absence of a queue can be based not only on an empty data structure, but also on a queue length attribute of zero, or the production building not having its path configuration function activated. This branching approach not only optimizes the underlying data processing flow but also ensures the immediacy of the initial path point generation, allowing players to receive lag-free visual feedback during their first operation.

[0046] In step S250, in response to the second operation for the virtual production object, a second path point is generated according to the second position corresponding to the second operation, and an ordered path node queue is generated according to the initial path point and the second path point. The second operation includes a basic triggering action and an auxiliary triggering action that cooperates with the basic triggering action.

[0047] By combining basic trigger actions with auxiliary trigger actions to form a second operation, players can quickly add new nodes to the ordered path node queue with intuitive combination operations, realizing convenient configuration and expansion of multi-node paths and effectively reducing the expression cost of multi-step deployment intentions.

[0048] Optionally, the second operation is used to trigger the additional expansion of path nodes. It consists of a combination of basic trigger actions and auxiliary trigger actions, aiming to distinguish between the intent to overwrite / reset and the intent to add / expand. Optionally, the second operation is an additional expansion operation distinct from the first operation (overwrite / reset). Its key lies in conveying the intent signal of "adding rather than overwriting" to the system through the cooperation of basic and auxiliary trigger actions. In one specific implementation, the second operation manifests as the player holding down the Shift key while right-clicking the target location on the map. The system recognizes that the Shift key is pressed and inserts the clicked location into the end of the ordered path node queue as an append operation. In another implementation, the second operation can manifest as the player touching the target location with two fingers on the touchscreen interface, with one finger touching a preset function area as an auxiliary trigger and the other finger clicking the target location as the basic trigger. It should be noted that the recognition logic of the second operation is not limited to the above examples. Any combination of operations that can orthogonally distinguish between the intent to add and the intent to overwrite should be included, thereby providing players with an intuitive means of path expansion interaction.

[0049] Optionally, the second position corresponds to the target coordinates specified by the second operation in the game scene, and is used to determine the spatial landing point of the second path point in the virtual map.

[0050] Optionally, the second location is the spatial coordinates pointed to by the second operation in the virtual game scene, used to determine the specific landing point of the newly added path node on the map. In one implementation, the second location can be the coordinates of a flat terrain on the map selected by the player by right-clicking the mouse; the system converts these coordinates into path node data and inserts them into the queue. In another implementation, the second location can also be the coordinates near a resource point on the map selected by the player by touching the screen; the system similarly records this as the spatial location of the new node. It should be noted that the selection of the second location is constrained by the accessibility of the game map. If the location specified by the player is in an inaccessible area such as water or a cliff, the system can automatically correct the location to the nearest accessible coordinates, or mark the location as inaccessible and prompt the player to reselect, to ensure the validity of each node in the path queue.

[0051] Optionally, the second path point is a path node generated based on the second position, appended to the end of the ordered path node queue as a subsequent transit node in the unit's movement path. Alternatively, the second path point is a path node data object generated based on the second position, appended to the end of the ordered path node queue as a subsequent transit node in the unit's movement path. In one implementation, the second path point includes position coordinate information and sequence number information. The system automatically assigns it an incrementing sequence number; if the original queue contains ① and ②, the new node is ③, and it is displayed in the visualization interface as a numbered marker icon. In another implementation, the second path point may also include a node type attribute, such as a transit node or a destination node. The system automatically determines its type based on its position in the queue and triggers a stop-and-wait instruction when the unit reaches the destination node. It should be noted that the generation of the second path point does not depend on the existence state of the initial path point. Even if the initial path point is removed for some reason, the second path point can still be retained in the queue as an independent node, ensuring the flexibility of path configuration.

[0052] Optionally, an ordered path node queue is used to store the multi-node path configuration of the production building, recording the arrangement order and coordinate information of each path node in the form of an ordered list.

[0053] Optionally, the ordered path node queue is an ordered list of path nodes maintained in the background for each virtual production object, used to store and manage the multi-node deployment path configuration of the building. In one implementation, the ordered path node queue is implemented using an array or linked list data structure, where each element contains fields such as node coordinates, sequence number, and node type. The system reads nodes sequentially according to the queue order and issues movement commands to new production units. In another implementation, the ordered path node queue may also include queue status indicators such as active or paused. When the queue is paused, new production units temporarily stay near the building, and automatically execute path movement after the queue becomes active again. It should be noted that there is no hard upper limit to the length of the ordered path node queue; players can continuously expand the number of nodes by repeatedly performing append operations, and this queue, as a persistent configuration, remains effective until it is overwritten or reset.

[0054] Optionally, auxiliary trigger actions are used in conjunction with basic trigger actions to identify additional extended intentions. The input forms include key input, touch input, or voice input. Optionally, auxiliary trigger actions are operation inputs executed in conjunction with basic trigger actions. Their key function is to identify to the system that the current operation is an additional extended intention rather than an overwrite / reset intention, thereby achieving orthogonal distinction between the two operation semantics. In one implementation, the auxiliary trigger action manifests as a player pressing and holding the Shift key. When the system detects that the Shift key is pressed, it determines the simultaneously occurring basic trigger action as an additional operation. In another implementation, the auxiliary trigger action can manifest as a player pressing the Ctrl or Alt key, or as a continuous touch operation on a specific functional area of ​​the touchscreen interface. It should be noted that the input type of auxiliary trigger actions is not limited to key input; it can also include voice input, such as the player issuing additional voice commands or gesture input, as long as it can form a recognizable combination signal with the basic trigger action, thus providing a flexible adaptation solution for different terminal platforms.

[0055] In one specific implementation, such as Figure 3 As shown, after the player selects virtual production object 310 on the map, virtual production object 310 is already configured with initial path point 301 (number ①). While holding down Shift (modifier key), the player right-clicks another reachable location on the map. The system adds this location as a second path point 302 (number ②) to the end of the ordered path node queue. The game view updates instantly, with a dotted line extending from the original end node (initial path point 301) to the newly added node (second path point 302). Similarly, if the player long-presses a preset function area on a touchscreen device while clicking the target location, the append semantics are also triggered, inserting the new node into the queue.

[0056] In another specific implementation, an ordered path node queue can be set up for multiple virtual production objects. These virtual production objects can be configured to share the same ordered path node queue based on player actions, or they can each correspond to different ordered path node queues. Taking multiple production objects sharing the same ordered path node queue as an example... Figure 4As shown, after the player selects a virtual production object 410 on the map, the virtual production object 410 is already configured with an initial pathpoint 401 (number ①). While holding down Shift (modifier key), the player right-clicks on another reachable location on the map. The system adds this location as a second pathpoint 402 (number ②) to the end of the ordered path node queue. The game view updates instantly, with a dotted line extending from the original end node (initial pathpoint 401) to the newly added node (second pathpoint 402). Furthermore, after the player selects a virtual production object 420 on the map, the virtual production object 420 is already configured with an initial pathpoint 401 (number ①) (or an initial pathpoint 401 can be set for the virtual production object 420 through the first operation). While holding down Shift (modifier key), the player right-clicks on the location of the second pathpoint 402 on the map. The system adds the second pathpoint 402 (number ②) to the end of the ordered path node queue. The game view updates instantly, with a dotted line extending from the original end node (initial pathpoint 401) to the newly added node (second pathpoint 402).

[0057] It should be noted that if the building does not currently have any ordered path node queue, the player can create the first path point by performing the second action. The system will directly use the position corresponding to the basic trigger action as the initial path point to establish the queue.

[0058] In an optional implementation, the method further includes: displaying a path identifier corresponding to an ordered path node queue in response to the fulfillment of a path display trigger condition; controlling the presentation and hiding of the path identifier by setting explicit trigger conditions, so that players can intuitively obtain path planning information when needed and avoid interface obstruction when not needed, effectively reducing the cognitive burden of multi-building management.

[0059] Optionally, the path display trigger condition is used to determine whether to display the path identifier in the graphical user interface. It can be dynamically determined based on the state changes of the virtual production object or the specific interactive instructions received.

[0060] Optionally, the path display trigger condition can include the virtual production object being selected. Considering that players need to frequently review the deployment routes of multiple production buildings when managing them, if the paths of all buildings are always displayed, it will severely obstruct the battlefield view and increase visual interference. As a possible implementation, when a player selects a barracks by drawing a box or clicking, the system determines that the trigger condition is met, immediately retrieves the ordered path node queue corresponding to that barracks, and renders the visual element; when the player clicks on a blank area or switches to selecting another object, the trigger condition is no longer met, and the path marker is hidden. This design allows path information to be presented instantly when needed and does not interfere with the view when not needed, achieving path management without the need for an additional interface. It should be noted that the above-mentioned selection state determination can be based on a real-time response to focus change events, ensuring no delay in visual feedback.

[0061] Optionally, in addition to triggering the display based on the selected state, the path display trigger conditions can also include the cursor hovering over a virtual production object for a preset duration, or receiving an activation operation for the path viewing control. To avoid frequent flickering of path markers when quickly moving the cursor over a building, the preset duration can be configured according to user habits, for example, set to 0.5 seconds. When the cursor stays on the building model for more than this duration, the system determines that the trigger condition is met and displays the complete path marker for that building; it is immediately hidden after the cursor moves away. By introducing a hover trigger mechanism, players can quickly preview the path without performing a formal selection operation, further reducing the interaction cost when managing multiple buildings in parallel and improving the smoothness of global strategic review.

[0062] Optionally, the path identifier is used to visually represent the direction and node distribution of an ordered queue of path nodes in a graphical user interface, and it includes at least part of the connecting line elements and node marker elements.

[0063] Optionally, path identifiers may include path lines connecting nodes sequentially from the virtual production object, and node markers located at each node's position. To enable players to intuitively distinguish the start and end points of the path and the execution order of each node, path lines may be dashed lines of a specified color (e.g., blue), while node markers may be circular or arrow icons with a serial number next to them. When the ordered path node queue contains only one node, the path identifier degenerates into a single dashed line, consistent with the traditional single-point aggregation visual. One objective of this embodiment is that, through the combination of lines and serial numbers, the overall picture of a multi-node path can be clearly displayed, and the order of unit movement can be clearly indicated, avoiding player confusion regarding the deployment logic.

[0064] Optionally, the display style of path markers can be dynamically adjusted based on the production status of virtual production objects or the terrain accessibility of path nodes. In one specific approach, when a path segment is obstructed by terrain, the marker for that segment can change color or flash to warn the player that the path requires a detour. When a new production unit is moving along the path, markers for the already traversed sections can gradually fade or disappear, while markers for the untraversed sections remain highlighted. It should be noted that the above dynamic style adjustment logic aims to provide richer status feedback, enabling path markers to function not only as static planning displays but also as dynamic progress indicators, further enhancing the efficiency of information delivery and the immersive experience of human-computer interaction.

[0065] In an optional implementation, the method further includes: in response to a third operation on the virtual production object, obtaining the currently ordered path node queue corresponding to the virtual production object, the third operation including a basic triggering action and an auxiliary triggering action in conjunction with the basic triggering action; inserting the third position corresponding to the third operation as a new path point into the end of the ordered path node queue to update the ordered path node queue.

[0066] By inserting the new position at the end of the queue through the third operation, players can flexibly expand multi-step deployment paths without having to reset the entire path, thus improving the efficiency and consistency of path configuration.

[0067] In one implementation, after a player selects a barracks on the map, which already has a rally path pointing to a resource point, the player holds down a modifier key on the keyboard and right-clicks on the frontline position on the map. The system retrieves the current ordered queue of path nodes for that barracks, appends the coordinates of the frontline position as a new node to the end of the queue, and displays the extended dotted path on the interface. Optionally, a third operation is used to indicate the interactive intent to append a new node to an existing queue, and its specific form can be adaptively configured according to the input device.

[0068] The third operation can be a combination of a basic trigger action and an auxiliary trigger action, and can be the same as the second operation. Considering the need for a clear distinction from resetting the entire queue, as a possible implementation, the third operation can be manifested as performing a click action while pressing a preset function key. It should be noted that the above-mentioned combined input form is only one example; in actual implementation, the third operation can also be manifested as a long-press click action, input via a specific gesture trajectory, or voice command input, etc. This application does not intend to limit the specific input form of the third operation. Through this orthogonal operation design, the system can accurately identify the player's additional intentions and avoid accidentally triggering and overriding the reset logic.

[0069] Optionally, a third position is used to represent the spatial coordinates of the new node in the virtual environment, which can be specified by the player in real time via an input device.

[0070] The third location can be any reachable surface coordinate point on the virtual map. When the player performs a third action, the system captures the corresponding world coordinates of the input device on the graphical user interface and determines it as the third location. This third location can be displayed directly in the game world view, or if the system determines that the location is in an impassable area, it can automatically navigate to the nearest reachable area and use that as the effective third location. It should be understood that the determination of the third location not only depends on the player's direct click, but can also be fine-tuned by combining terrain elevation data, building collision volume, and other parameters to ensure that subsequently generated virtual objects can successfully reach it.

[0071] Optionally, a new waypoint, as a newly added data node in the ordered path node queue, must at least contain spatial location information and sequence number information. In addition to the three-dimensional coordinate data corresponding to the third position, the new waypoint may also contain other attribute information, such as waiting instructions and dwell time, which can further enrich the behavioral logic after the unit arrives. When a new waypoint is inserted at the end of the ordered path node queue, the system automatically assigns it a sequential sequence number and updates the queue length parameter. It should be noted that the above description of the data composition of new waypoints is not intended to be restrictive; new waypoints may also only store the most basic coordinate information, with the system dynamically calculating the sequence number during scheduling, thereby reducing data storage overhead.

[0072] In one specific embodiment, after the player selects a virtual production object 310 on the map, the virtual production object 310 is already configured with an initial path point 301 (number ①). While holding down Shift (modifier key), the player right-clicks another reachable location on the map (second operation). The system adds this location as a second path point 302 (number ②) to the end of the ordered path node queue. The game view is updated instantly, with a dotted line extending from the original end node (initial path point 301) to the newly added node (second path point 302). Then, while holding down Shift (modifier key) again, the player right-clicks yet another reachable location on the map (third operation). The system adds this location as a third path point 303 (number ③) to the end of the ordered path node queue. The game view is updated instantly, with a dotted line extending from the original end node (second path point 302) to the newly added node (third path point 303).

[0073] In another specific implementation, an ordered path node queue can be set up for multiple virtual production objects. These virtual production objects can be configured to share the same ordered path node queue based on player actions, or they can each correspond to different ordered path node queues. Taking multiple production objects sharing the same ordered path node queue as an example... Figure 4 As shown, after the player selects the virtual production object 410 on the map, the virtual production object 410 is already configured with an initial path point 401 (number ①). While holding down Shift (modifier key), the player right-clicks another reachable location on the map (second operation). The system adds this location as a second path point 402 (number ②) to the end of the ordered path node queue. The game view updates instantly, and the dotted line extends from the original end node (initial path point 401) to the newly added node (second path point 402). Then, while holding down Shift (modifier key) again, the player right-clicks another reachable location on the map (third operation). The system adds this location as a third path point 403 (number ③) to the end of the ordered path node queue. The game view updates instantly, and the dotted line extends from the original end node (second path point 402) to the newly added node (third path point 403). This completes the path point setting for the virtual production object 410 and generates a path from the virtual production object 410 to the initial path point 401, then to the second path point 402, and finally to the third path point 403. Furthermore, after the player selects the virtual production object 420 on the map, which is already configured with an initial pathpoint 401 (number ①), the player holds down Shift (modifier key) and right-clicks on the location of the second pathpoint 402 on the map (second operation). The system appends the second pathpoint 402 (number ②) to the end of the ordered path node queue, and the game view updates instantly, with the dotted line extending from the original end node (initial pathpoint 401) to the newly added node (second pathpoint 402). Then, the player holds down Shift again... While pressing t (modifier key), right-click on the location of the third path point 403 on the map (third operation). The system will add the third path point 403 (serial number ③) to the end of the ordered path node queue. The game view will be updated in real time, and the dotted line will extend from the original end node (second path point 402) to the newly added node (third path point 403), completing the path point setting for the virtual production object 420 and generating a travel path of virtual production object 420 --- initial path point 401 --- second path point 402 --- third path point 403.

[0074] In optional implementations, the input types for basic trigger actions and auxiliary trigger actions include key input, touch input, or voice input.

[0075] By supporting multiple input types, the solution can flexibly adapt to different hardware platforms and interaction habits, effectively improving the universality and ease of operation of human-computer interaction.

[0076] For example, in a personal computer scenario, the basic trigger action can be a right-click operation, while the auxiliary trigger action can be a right-click operation performed while holding down the Shift modifier key on the keyboard. In a mobile terminal scenario, the basic trigger action can be a single-finger tap operation, while the auxiliary trigger action can be a two-finger long press and tap operation. In scenarios that support voice interaction, players can say "set waypoint" as the basic trigger action and "add waypoint" as the auxiliary trigger action, and the system will use voice recognition to generate the corresponding waypoints and update the queue.

[0077] Optionally, the input type is used to receive trigger actions, including key input, touch input, or voice input, to adapt to different terminal devices. Optionally, key input can be achieved through the letter keys, number keys, or function keys of an external physical keyboard, or through pressing the left or right mouse button or scroll wheel; touch input can be recognized by detecting user clicks, long presses, swipes, or multi-finger gestures on the touchscreen; voice input can receive the user's natural language commands through an audio acquisition device and convert them into corresponding operation signals using a semantic parsing model. It should be noted that the above description of input types is only one example and is not intended to limit the scope. In actual implementation, the input types can be flexibly combined according to the device's interaction capabilities. For example, in a hybrid interaction scenario, basic trigger actions can use touch input, while auxiliary trigger actions can use voice input, thereby meeting the needs of users with different operating habits and improving the robustness of multi-terminal adaptation.

[0078] In an optional implementation, the basic trigger action is a click operation on the target location, and the auxiliary trigger action is a press operation on a preset function key. By concretizing the basic trigger action and the auxiliary trigger action as a click operation and a press operation on a preset function key, respectively, the physical input difference between the two configuration intentions is clarified, making the semantic opposition between adding nodes and overwriting / resetting operations more intuitive and reducing the risk of misoperation by players in large-scale battlefield environments.

[0079] In one implementation, after selecting a barracks building on the map, if a player wants to reset the waypoint, they simply move the mouse cursor to the target location and right-click. The system immediately clears the old queue and uses that location as the initial waypoint. If the player wants to add a new node without disrupting the existing path, they must hold down the Shift key and right-click on another reachable area on the map. The system inserts that location at the end of the queue. It should be noted that this combination of operations reuses the Shift stacking operation habit already present in strategy games, so players do not need to learn a completely new operation paradigm.

[0080] Optionally, the target location indicates the spatial coordinates of the path node configured for the virtual production object within the game scene. It can be any accessible ground area on the map. Optionally, the target location can be a flat area in the game scene not obstructed by terrain, or a strategically important narrow passage such as a bridge or pass. Considering the direct impact of terrain on unit movement in strategy games, the determination of the target location usually needs to be combined with the accessibility judgment of the pathfinding system to avoid players setting nodes in inaccessible areas such as isolated islands or cliffs. If a player mistakenly specifies the target location in an inaccessible area, the system can handle this error by highlighting the location or automatically snapping it to the nearest accessible point. It should be noted that the target location is not limited to surface coordinates; in game settings containing multi-layered terrain or aerial units, it can also be three-dimensional spatial coordinates at a specific height level. This application does not impose any limitations on this.

[0081] Optionally, the click action is used as a specific manifestation of the basic trigger action to convey the intention of setting the waypoint to the system.

[0082] Optionally, the click operation can be a single press of the right mouse button or a trigger action triggered by the left mouse button in conjunction with a specific interface button. To avoid conflicts with the interface's conventional left-click functions such as selection and selection boxes, the click operation is preferably a right-click operation, thereby directly utilizing the context menu feature of the right button to complete the location specification without adding additional interface controls. In one implementation of the touch terminal, the click operation can also evolve into a touch gesture of pressing and holding a map area with one finger for more than a preset time and then releasing it. The system obtains the touch point coordinates as the target location when it detects the end of the gesture. It should be understood that the specific form of the click operation can be adaptively switched according to the type of input device, and this application does not intend to exhaustively limit its physical input methods.

[0083] Optionally, preset function keys are used in conjunction with basic trigger actions to clearly indicate to the system the operational intent of adding nodes.

[0084] Optionally, the preset function keys can be modifier keys on a keyboard, such as the Shift, Ctrl, or Alt keys, or shoulder or back buttons on a gamepad controller. One objective of this embodiment is to enable the system to parse two different configuration semantics under the same basic trigger action by introducing the pressed state of the preset function keys as auxiliary trigger signals. This reduces interface complexity and improves operational consistency.

[0085] In one specific approach, the system listens for basic trigger actions while simultaneously polling the key value status of preset function keys in real time. If a preset function key is detected as pressed, the current operation is interpreted as append semantics; otherwise, it is interpreted as overwrite semantics. It should be noted that the mapping relationship of preset function keys can be customized by the player in the settings interface to accommodate different operating habits.

[0086] Optionally, the pressing operation is used to characterize the mechanical force applied by the player to the physical input device, generating an electrical signal as the input source for auxiliary triggering actions. Optionally, the pressing operation can be the pressing and rebounding action of a mechanical keyboard key switch, or the touch sensing action of a membrane key or capacitive touch key. Considering the differences in trigger travel and feedback force of different input devices, the system can combine the pressing duration or pressure threshold for anti-bounce processing when determining whether the pressing operation is effective, in order to avoid abnormal queue updates caused by accidental touches. For example, when the pressing duration of a preset function key is less than 50 milliseconds, the system can determine it as invalid bounce and ignore it; when the pressing duration exceeds the threshold and is accompanied by a basic triggering action, the node appending logic is executed. Similarly, in devices that support force feedback, the pressing operation can also trigger different auxiliary functions according to the magnitude of the pressing force, which is not limited in this embodiment.

[0087] In an optional implementation, the click operation is a right-click operation, and the default function key is a modifier key.

[0088] In one implementation, after a player selects a virtual production object, they move the mouse cursor to the target location on the map and right-click. The system recognizes this right-click operation as the first operation and generates an initial waypoint. Subsequently, the player holds down the Shift key (i.e., the modifier key) on the keyboard and right-clicks at another target location. The system recognizes this combination of operations as the second operation, generates a second waypoint, and inserts it at the end of the queue.

[0089] Optionally, the right-click action is used to instruct the system to perform an overwrite reset or to perform an additional action in conjunction with auxiliary actions. It can be represented by a single press or a series of clicks.

[0090] Optionally, a right-click operation can be a pressing action performed by the player using the right mouse button on the graphical user interface. Considering that players frequently use the right mouse button to issue movement commands in strategy games (real-time strategy / simulation games), using it as a basic trigger action can seamlessly connect with the player's existing muscle memory and reduce the learning cost. Specific triggering conditions for a right-click operation can include: detecting that the mouse cursor is in a reachable area on the map, and receiving a right-click press signal and a subsequent release signal. It should be noted that a right-click operation is not limited to a single click. In an alternative implementation, it can also be an operation of pressing and holding the right button, dragging along a specified trajectory, and then releasing it, as long as the system can resolve a clear target location. In addition, for touch terminals, the right-click operation can be equivalently mapped through touch gestures such as single-finger long press or two-finger click, thereby ensuring the consistency of cross-platform operation logic.

[0091] Optionally, modifier keys are used to change the default semantics of the basic trigger action, switching it from overriding mode to appending mode. These can include designated function keys on the keyboard. Optionally, modifier keys can be auxiliary keys on the keyboard used to change the default semantics of other keys or operations, such as the Shift key, Ctrl key, or Alt key. To avoid command conflicts with ordinary right-click operations (overriding reset), the system distinguishes between the player's appending and overriding intentions by detecting the pressed state of the modifier key. In specific implementations, the system can detect whether the modifier key is in an active state before, during, or after the right-click event is detected. If the modifier key is active, the right-click is interpreted as an append node instruction; if it is not active, it is interpreted as an overriding reset instruction. It should be noted that the selection of modifier keys can be flexibly adjusted according to the player's custom configuration, and this application does not intend to limit the specific physical location of the modifier keys. In a foolproof mechanism, if the player presses multiple modifier keys simultaneously, the system can select one to respond to according to a preset priority, or ignore the operation to avoid accidental presses.

[0092] In an optional implementation, displaying path identifiers corresponding to the ordered path node queue includes: displaying path connection identifiers between the virtual production object and the first node in the ordered path node queue, and between adjacent nodes in the ordered path node queue; and displaying node marker identifiers at the positions of each node in the ordered path node queue.

[0093] By combining path connection markers and node markers, the overall direction of a multi-node path can be presented intuitively in the form of segmented connections. At the same time, the markers at the node positions clearly indicate the execution order of each node, avoiding confusion for players regarding the deployment logic. Furthermore, when the queue contains only a single node, it degenerates into a single-segment connection display, maintaining compatibility with traditional single-point assembly visuals and effectively improving the visual readability and deployment accuracy of path planning.

[0094] In one implementation, after a player selects a barracks building on the map, the graphical user interface automatically displays a visualization of the rally path corresponding to that barracks. Specifically, starting from the barracks exit, a dotted line connects sequentially to path points ①, ②, and ③, with a circular marker icon bearing a serial number displayed at each path point. Players can confirm the path's direction and the order of each node with a single visual scan. It should be noted that when a player sets only one path point, the interface only displays a single dotted line segment from the barracks to path point ①, consistent with the traditional single-point rally visual representation.

[0095] Optionally, when the ordered path node queue contains only one node, a path connection identifier is displayed between the virtual production object and the node.

[0096] Optionally, path connection markers are used to establish visual connections between virtual production objects and path nodes. Their presentation can include various forms such as dashed lines, solid lines, or gradient lines. Optionally, path connection markers can be dashed lines, solid green lines, or gradient lines with directional arrows. Considering that players need to quickly distinguish the path directions of different buildings when managing multiple buildings in parallel, the visual parameters of the path connection markers, such as color, line type, and transparency, can be dynamically configured according to the virtual production object's faction affiliation, building type, or path status. It should be noted that the starting point of the path connection marker can be set at the exit position of the virtual production object, or at the center position of the virtual production object, or at other preset anchor points; this application is not intended to limit this. When the ordered path node queue contains multiple nodes, the path connection markers connect adjacent nodes sequentially in segments to form a complete path direction indication; when the queue contains only a single node, the path connection marker degenerates into a single-segment connection, maintaining compatibility with the visual representation of traditional path points, ensuring that players can obtain a consistent visual cognitive experience under different configuration states.

[0097] Optionally, node markers are used to visually label the positions of each node in an ordered path node queue, and they include at least a location indicator graphic and sequence number information to distinguish the order of each node.

[0098] Optionally, node markers can be in the form of circular icons, arrow icons, flag icons, or diamond-shaped logos, with a serial number (such as ①②③ or numerical codes like 1, 2, 3, etc.). To avoid players confusing node markers of different buildings in complex battlefield environments, the graphic style, size, and color scheme of the node markers can be differentiated according to the node's serial number in the queue, node type, or building it belongs to. It should be noted that node markers not only serve as location indicators but can also include extended information, such as estimated arrival time and the number of units currently en route. This extended information can further assist players in making deployment decisions. In actual implementation, node markers can be displayed when a virtual production object is selected, or highlighted or enlarged when the player's cursor is detected hovering near a node; this embodiment does not limit this.

[0099] In an optional implementation, the path display triggering condition includes: the virtual production object is in a selected state; the method further includes: in response to the virtual production object switching from a selected state to an unselected state, canceling the display of the path identifier corresponding to the ordered path node queue.

[0100] By binding the display of path markers to the selection status of virtual production objects, on-demand presentation and automatic hiding of path information are achieved. This effectively avoids the continuous obstruction of the main battlefield view by path lines in multi-building scenarios, reducing visual interference and cognitive burden for players. In one implementation, when a player selects a barracks building on the game map, dotted lines and serial numbers connecting the barracks to various path points immediately appear on the graphical user interface, allowing players to quickly review deployment routes. When the player clicks on a blank area of ​​the map or switches to selecting other units, the barracks is deselected, and the aforementioned dotted lines and markers disappear, restoring the interface to a clean global battlefield view. This allows players to obtain path information instantly when needed, while remaining free from interference from unnecessary interface elements when focusing on combat.

[0101] Optionally, the path display trigger condition is used to define when the path identifier is displayed in the graphical user interface, which can be dynamically triggered based on the interaction status of the virtual production object.

[0102] Optionally, the path display trigger condition can be the instantaneous state when the virtual production object is selected by a specified input action, or any moment when the virtual production object is in a continuously selected phase. Considering that in a large-scale battlefield environment with multiple buildings operating in parallel, if the path markers of all buildings are permanently displayed, it will lead to cluttered interface lines and severely obscure terrain and combat units. This embodiment uses the selected state as an explicit trigger condition to achieve a "what you see is what you need" on-demand rendering mechanism. It should be noted that the determination of the above-mentioned selected state is not limited to a single click selection with the left mouse button, but can also include interactive methods such as cycling the focus through shortcut keys or clicking the avatar through the grouping panel. As long as the system determines that the production building becomes the focus object currently controlled by the player, the generation and display of path markers can be triggered, and these markers can be immediately hidden when the focus shifts. Thus, without adding additional interface switches, it balances the convenience of information acquisition and the cleanliness of the field of view.

[0103] In an optional implementation, the ordered path node queue is configured as persistent data. Before the ordered path node queue corresponding to the virtual production object is reset, in response to at least one second virtual object subsequently produced by the virtual production object, at least one second virtual object is controlled to move sequentially according to the node order in the ordered path node queue. By configuring the ordered path node queue as persistent data, subsequently produced virtual objects can automatically inherit and execute existing paths, avoiding the tedious operation of repeated configuration and realizing automated continuous scheduling of batch units.

[0104] In one implementation, after a player selects an archery tower on the map and configures an ordered path node queue containing three nodes, this queue is marked as persistent data stored in the background. After a period of time, the archery tower successively produces multiple archers. Each archer, upon appearing at its spawn location, independently reads the persistent queue configuration and moves sequentially to the first node, the second node, and the third node. During this process, the player does not need to perform any additional path setting operations.

[0105] Optionally, persistent data is used to maintain the validity of the ordered path node queue throughout the lifecycle of the virtual produced object, so that it continues to affect subsequently produced virtual objects before being explicitly reset.

[0106] Optionally, persistent data can be configuration files stored on the terminal's local storage medium, data structure instances residing in runtime memory, or player strategy records maintained by a server-side database. Considering that players may experience application crashes or network disconnections during gameplay, configuring the ordered path node queue as persistent data ensures that the player's pre-planned complex multi-node paths are not lost due to unexpected interruptions. When the player re-enters the game, the system can read the queue from the persistent data and restore the configuration, thus ensuring the continuity and stability of the deployment strategy. It should be noted that the storage granularity of persistent data can be precise down to a single virtual production object; that is, each building independently maintains its own persistent path record, without interference.

[0107] Optionally, the second virtual object is used to represent the virtual unit that needs to automatically execute the queue path after the ordered path node queue is configured and subsequently generated by the virtual production object.

[0108] Optionally, the second virtual object can be a virtual character with different combat attributes or auxiliary functions, such as a melee infantryman, a ranged archer, or a gathering unit. Each second virtual object, upon creation, independently obtains a reference or snapshot of the ordered path node queue corresponding to the current virtual production object and executes movement commands independently based on its own attributes, thus supporting multiple units simultaneously on their way without blocking each other. To avoid pathfinding congestion caused by a large number of units clustering at the same node, the system can also incorporate a dynamic collision avoidance strategy when controlling the movement of second virtual objects, ensuring that multiple second virtual objects are dispersed when reaching the same target node. It should be understood that the number and generation frequency of second virtual objects depend on the production queue arrangement of the virtual production object; regardless of how many second virtual objects are generated, as long as the queue is not reset, an automatic movement mechanism will be triggered.

[0109] In step S270, in response to the production of a first virtual object by a virtual production object, the first virtual object is controlled to move sequentially according to the node order in the ordered path node queue. This enables new production units to automatically execute multi-node path deployment without requiring the player to manually issue commands segment by segment, improving the automation level and deployment efficiency of unit scheduling. In one implementation, the player pre-configures an ordered path node queue containing three nodes for the barracks. When an infantry unit is produced by the barracks, the infantry unit is generated at the barracks entrance. The system immediately reads the ordered path node queue, controls the infantry unit to first move to the resource point, then continue moving to the valley pass, and finally arrive at the front-line position, all without player intervention.

[0110] Optionally, the first virtual object refers to a movable entity generated by a virtual production object and controlled by the player or system. Optionally, the first virtual object can be various types of virtual characters, such as infantry units, cavalry units, siege engines, or flying units. Considering the differences in unit types produced by different production buildings, the first virtual object is usually generated near the exit of the virtual production object or at specified coordinates. It should be noted that the above description of the first virtual object type is only one example and is not intended to limit it. In actual implementation, the first virtual object can also be a hero unit with special skills or a non-combat logistics unit, and its specific attributes can be dynamically configured according to game strategy requirements, thereby enriching the application scenarios of path deployment.

[0111] Optionally, node order is used to indicate the order in which path nodes are arranged in an ordered path node queue.

[0112] Optionally, the node order can be represented by index values, linked list pointers, or timestamps in the queue data structure to ensure that the first virtual object can pass through each node sequentially according to a predetermined logic. One objective of this embodiment is to prevent newly produced units from getting lost or wandering aimlessly in complex terrain through strict node order constraints. In practical implementation, the node order not only reflects the spatial transfer path but also implies the logical chain of tactical execution, such as passing through concealed points before launching an attack. It should be understood that the node order remains fixed until the ordered path node queue is reset or modified, ensuring that multiple first virtual objects produced by the same virtual production object can follow the same route, guaranteeing the consistency of troop concentration.

[0113] In an optional implementation, controlling the first virtual object to move sequentially according to the node order in the ordered path node queue includes: controlling the first virtual object to move towards the target node in the ordered path node queue; when the path of the first virtual object to the target node is detected to be blocked by terrain, controlling the first virtual object to perform pathfinding and detour, and continuing to move towards the target node after detour is completed. This avoids path interruption or jamming caused by obstacles during the movement of units to multiple nodes, ensures the continuous execution of deployment commands, and thus significantly improves the robustness and automation of troop deployment in complex terrain.

[0114] In practical application, players configure an ordered path node queue for their barracks, consisting of three nodes: a supply point, a rendezvous point, and a forward position. When a barracks produces an infantryman, the infantry automatically moves towards the first target node. During this movement, if an insurmountable cliff exists between two nodes, the system automatically triggers a pathfinding mechanism, guiding the infantry to traverse along the walkable area along the cliff edge. After successfully circumventing the cliff, the infantry automatically resumes its original route towards the supply point without requiring further player intervention, and then proceeds to the next node upon arrival.

[0115] Optionally, the target node indicates the path position that the first virtual object needs to reach, and it is determined sequentially according to the order of the ordered path node queue. Optionally, the target node can be any node in the queue after the current position, and its specific form can include map coordinates, specific building locations, or area center points, etc. To achieve precise movement control, in addition to spatial coordinate information, the target node can also contain behavioral instructions after arrival, such as stay, attack, or patrol. It should be noted that the above description of the target node attributes is only one example, and this application is not intended to limit the composition of this feature. In actual implementation, the system can use a cursor pointer or index value to mark the current target node. Whenever the first virtual object reaches the current target node, the index value is automatically incremented to point to the next node. Considering the scenario of parallel scheduling of multiple units, the target nodes corresponding to different first virtual objects at the same time may be the same or different. The system will independently maintain the current target node reading status for each object to avoid mutual interference.

[0116] Optionally, terrain obstruction is used to characterize obstacle elements in the virtual environment that hinder the straight-line movement of the first virtual object, and it is dynamically determined based on the navigation grid data of the scene map. Optionally, the specific form of terrain obstruction can be diverse, including at least impassable areas, areas with excessive height differences, or enclosed water areas. In one embodiment, terrain obstruction can be represented as steep mountains or abysses marked as non-walkable areas on the map; in another embodiment, terrain obstruction can also be a temporarily generated dynamic obstacle, such as a bridge that has collapsed after being destroyed or a densely packed formation of friendly forces. To avoid abnormal situations such as units getting stuck or clipping through walls due to delays in terrain data updates, the above method can combine the collision volume of the first virtual object with the boundary of the navigation grid for intersection calculation when detecting the movement path. If the path intersects with the obstruction area, it is determined to be obstructed by terrain; for partially destructible obstructions, the system can also further determine whether the first virtual object has the ability to clear them. If it does, it is not considered an absolute obstruction, and this application embodiment does not limit this.

[0117] Optionally, pathfinding detour is used to dynamically generate alternative paths when encountering terrain obstacles, so as to ensure that the first virtual object can continue to advance towards the target node.

[0118] Optionally, pathfinding and detours can be implemented by recalculating a collision-free path from the current position to the target node within the walkable area based on a preset pathfinding algorithm. One objective of this embodiment is to reduce the data processing workload of manual player micro-management through an automated detour mechanism, while also ensuring the integrity of multi-node path execution. Besides recalculating the optimal path through the global navigation grid, a local obstacle avoidance algorithm can also be used for temporary detours, such as generating temporary pathpoints at the edges of obstacles and guiding the object along those points. It should be understood that in complex battlefield environments, the detour path may deviate significantly from the original straight path. If new terrain obstacles are encountered during the detour, the system will iteratively execute the aforementioned detection and detour logic until the target node is reached or the node is determined to be completely unreachable. If completely unreachable, the first virtual object can be controlled to stay at the nearest safe location and a prompt message can be generated to ensure the stability of the system state.

[0119] In an optional implementation, the method further includes: in response to the virtual production object producing a first virtual object, obtaining the currently corresponding ordered path node queue of the virtual production object; and controlling the first virtual object to remain at its generation location when the ordered path node queue is empty. By controlling the first virtual object to remain at its generation location when the ordered path node queue is empty, the compatibility and stability of the behavior of newly produced units when no path is configured are ensured, avoiding disordered unit movement or logical errors, and improving the robustness of the system. In practical applications, when a player has just completed the construction of a barracks-type production building and has not yet set any rally path for it, the ordered path node queue corresponding to that building is empty. If the building then produces an infantry unit, and the system detects that the queue is empty, it controls the infantry unit to remain stationary at its generation location at the barracks entrance, waiting for the player to manually issue a movement command, thus maintaining consistency with the game behavior before the introduction of a multi-node path mechanism.

[0120] Optionally, an empty ordered path node queue indicates that the virtual production object is not currently configured with any path nodes, triggering the system's default unit dwell behavior. Optionally, an empty ordered path node queue can include the state when the virtual production object has been initially built and has not received any path setting operations, or the state after the player has actively cleared all configured nodes. Considering that queue data may be lost due to accidental operations or system anomalies during game operation, making an empty queue an independent judgment condition can effectively avoid pathfinding logic errors or disordered wandering caused by the lack of target nodes for newly produced units. It should be noted that the timing of the above-mentioned empty queue state judgment is not limited to the moment the unit is completed; it can also be pre-checked at specific stages of the production process to allocate corresponding logical resources for the unit's dwell behavior in advance, ensuring a smooth state transition.

[0121] Optionally, the generation location indicates the spatial coordinates of the first virtual object's spawn point in the scene, serving as the default anchor point for virtual objects when no path is configured. Optionally, the generation location can be the model center point of the virtual object, or a pre-defined building exit coordinate or a specific vacant area around the building. In one specific implementation, to prevent multiple first virtual objects from overlapping and getting stuck at the same generation location, the generation location can be dynamically shifted based on the number of units already stationed there, allowing subsequently generated units to be arranged and stationed sequentially in a scattering or queue pattern around the original generation location. One objective of this embodiment is that by explicitly defining the generation location as the default anchor point in a pathless state, it ensures that units have legitimate footholds after production, and also facilitates players' visual quick location of buildings without configured paths, enabling timely subsequent path planning or manual scheduling.

[0122] The following is for reference. Figure 5 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 5 The electronic device 600 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0123] like Figure 5 As shown, the electronic device 600 may include: a processor 610, a memory 620, a bus 630, an I / O (input / output) interface 640, a network adapter 650, and a display 660.

[0124] The memory 620 may include volatile memory, such as RAM 621 and cache unit 622, and may also include non-volatile memory, such as ROM 623. The memory 620 may also include one or more program modules 624, including but not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 624 may include the modules described above.

[0125] Processor 610 may include one or more processing units, such as: AP (Application Processor), modem processor, GPU (Graphics Processing Unit), ISP (Image Signal Processor), controller, encoder, decoder, DSP (Digital Signal Processor), baseband processor and / or NPU (Neural-Network Processing Unit).

[0126] The processor 610 can be used to execute executable instructions stored in the memory 620 to perform the methods described above in this disclosure.

[0127] Bus 630 is used to connect different components of electronic device 600 and may include a data bus, an address bus and a control bus.

[0128] Electronic device 600 can communicate with one or more external devices 700 (such as keyboard, mouse, external controller, etc.) through I / O interface 640.

[0129] Electronic device 600 can communicate with one or more networks via network adapter 650. For example, network adapter 650 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 650 can communicate with other modules of electronic device 600 via bus 630.

[0130] Electronic device 600 can display a graphical user interface via display 660.

[0131] although Figure 5Other hardware and / or software modules may also be configured in the electronic device 600, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0132] Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0133] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0134] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0135] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. An information processing method, characterized in that, The method includes: Display virtual production objects in the graphical user interface; In response to a first operation on the virtual production object, an initial path point is generated based on a first position corresponding to the first operation, wherein the first operation includes a basic triggering action. In response to a second operation on the virtual production object, a second path point is generated based on the second position corresponding to the second operation, and an ordered path node queue is generated based on the initial path point and the second path point. The second operation includes the basic triggering action and auxiliary triggering actions that cooperate with the basic triggering action. In response to the virtual production object producing a first virtual object, the first virtual object is controlled to move sequentially according to the node order in the ordered path node queue.

2. The method according to claim 1, characterized in that, The method further includes: In response to the fulfillment of the path display trigger condition, the path identifier corresponding to the ordered path node queue is displayed.

3. The method according to claim 1, characterized in that, The step of generating an initial path point in response to a first operation on the virtual production object, based on a first position corresponding to the first operation, includes: In response to the first operation on the virtual production object, if the virtual production object already has an existing path node queue, the existing path node queue is cleared. The first position is used as the initial path point.

4. The method according to claim 1, characterized in that, The method further includes: In response to the third operation for the virtual production object, the ordered path node queue currently corresponding to the virtual production object is obtained, wherein the second operation includes the basic triggering action and the auxiliary triggering action in conjunction with the basic triggering action; The third position corresponding to the third operation is inserted as a new path point to the end of the ordered path node queue to update the ordered path node queue.

5. The method according to claim 1, characterized in that, The input types for the basic trigger action and the auxiliary trigger action include key input, touch input, or voice input.

6. The method according to claim 5, characterized in that, The basic trigger action is a click operation on the target location, and the auxiliary trigger action is a press operation on a preset function key.

7. The method according to claim 1, characterized in that, The display of the path identifier corresponding to the ordered path node queue includes: A path connection identifier is displayed between the virtual production object and the first node in the ordered path node queue, as well as between adjacent nodes in the ordered path node queue. At each node position in the ordered path node queue, a node marker is displayed.

8. The method according to claim 1, characterized in that, The ordered path node queue is configured as persistent data; Before the ordered path node queue corresponding to the virtual production object is reset, in response to at least one second virtual object subsequently produced by the virtual production object, the at least one second virtual object is controlled to move sequentially according to the node order in the ordered path node queue.

9. The method according to claim 1, characterized in that, The control of the first virtual object to move sequentially according to the node order in the ordered path node queue includes: Control the first virtual object to move towards the target node in the ordered path node queue; When the path of the first virtual object to the target node is blocked by terrain, the first virtual object is controlled to find a way around and continue to move towards the target node after the detour is completed.

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

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, are used to implement the information processing method as described in any one of claims 1 to 9.

Images