Display control method, electronic device, and computer-readable storage medium

Abstract

An embodiment of the present disclosure provides a display control method, an electronic device and a storage medium. The display control method comprises: in response to a designation instruction for a target position in a map interface, determining a virtual observation point in a virtual scene; and controlling a display preview picture according to a relative position relationship between the virtual observation point and a controlled virtual character, wherein the preview picture is rendered according to virtual camera parameters, the virtual camera parameters include a line-of-sight direction, the line-of-sight direction has the virtual observation point as a starting point and the controlled virtual object as an ending point. In this way, the virtual observation point is triggered through the map interface and the preview picture is rendered, which helps to reduce repeated rendering requests caused by frequent adjustment of the position of the character by the user to confirm the model occlusion state, and reduces the data processing pressure of the terminal and the rendering resource occupation.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to display control methods, electronic devices, and computer-readable storage media. Background Technology

[0002] In multiplayer competitive games, players need to move around the scene, aim and attack enemy targets, use terrain cover to avoid attacks and complete tactical missions.

[0003] In related technologies, players typically rely on a first-person perspective to observe their surroundings and combine this with location markers on the game map to understand battlefield terrain information. The game map is mainly used to display scene area information and teammate distribution to assist players in navigation and route planning. However, players often struggle to accurately assess their exposure risk behind cover, frequently relying on experience or frequently adjusting their character's position for verification, resulting in a cumbersome interaction process. This process easily generates a large number of repetitive location synchronization requests and scene rendering commands, increasing the terminal's computational load and data processing pressure. Summary of the Invention

[0004] This disclosure provides a display control method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this disclosure, a display control method is provided, which provides a graphical user interface (GUI) via a terminal. The GUI displays at least a portion of a virtual scene, the virtual scene including a controlled virtual character. The method includes: displaying a map interface via the GUI, wherein the map interface is used to display area information of the virtual scene and includes a first location identifier, wherein the first location identifier is used to identify the position of the controlled virtual character in the virtual scene; determining a virtual observation point in the virtual scene in response to an instruction to specify a target location in the map interface; and controlling the display of a preview screen based on the relative positional relationship between the virtual observation point and the controlled virtual character, wherein the preview screen is rendered based on virtual camera parameters, wherein the virtual camera parameters include a viewing direction, wherein the viewing direction originates from the virtual observation point and faces the controlled virtual object.

[0006] According to one aspect of this disclosure, a display control device is provided, which provides a graphical user interface (GUI) via a terminal. The GUI displays at least a portion of a virtual scene, the virtual scene including a controlled virtual character. The device includes: a display module for displaying a map interface via the GUI, wherein the map interface is used to display area information of the virtual scene and includes a first location identifier, wherein the first location identifier is used to identify the position of the controlled virtual character in the virtual scene; a determination module for determining a virtual observation point in the virtual scene based on a specified instruction for a target location in the map interface; and a generation module for controlling the display of a preview screen based on the relative positional relationship between the virtual observation point and the controlled virtual character, wherein the preview screen is rendered based on virtual camera parameters, wherein the virtual camera parameters include a viewing direction, wherein the viewing direction originates from the virtual observation point and faces the controlled virtual object.

[0007] According to one aspect of this disclosure, 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 implements any of the above methods when executing the computer program instructions.

[0008] According to one aspect of this disclosure, 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 above methods.

[0009] One embodiment of this disclosure provides a display control method, comprising: displaying a map interface through a graphical user interface, wherein the map interface is used to display area information of a virtual scene and includes a first location identifier, wherein the first location identifier is used to identify the position of a controlled virtual character in the virtual scene; determining a virtual observation point in the virtual scene in response to an instruction to specify a target location in the map interface; and controlling the display of a preview screen according to the relative positional relationship between the virtual observation point and the controlled virtual character, wherein the preview screen is rendered according to virtual camera parameters, wherein the virtual camera parameters include a viewing direction, wherein the viewing direction originates from the virtual observation point and faces the controlled virtual object. Thus, triggering the virtual observation point and rendering the preview screen through the map interface helps reduce the repetitive rendering requests caused by users frequently adjusting the character's position to confirm the model's occlusion status, reducing terminal data processing pressure and rendering resource consumption, and improving the accuracy of occlusion judgment and human-computer interaction efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this disclosure, 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 disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This diagram illustrates a flow chart of a display control method provided in one exemplary embodiment of the present disclosure. Figure 2 This diagram illustrates the structure of a display control device provided in one exemplary embodiment of the present disclosure. Figure 3 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0012] The technical solutions of this disclosure will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0013] This embodiment provides a method that provides a graphical user interface (GUI) through a terminal device. The GUI displays a game interface, which includes a game scene and a user interface (UI). The game interface refers to the interface of an application provided or displayed through the GUI. The user interface is used for information interaction with the user and may include game design elements that directly or indirectly interact with the user, such as buttons, animations, text, sounds, and windows. In optional embodiments, the interface elements in the user interface may include the following controls: (1) controls related to the character, such as skill controls, movement controls, and function controls; (2) controls for indicating information, also known as indicator information markers, such as direction indicators, character indicators, character stamina indicators, item pickup points, or treasure chest locations; (3) information display controls, also known as information display areas, such as displaying basic character information (character name, profession, health points, mana points, etc.), character status information (such as whether the character is unconscious or poisoned), or match information (such as the number of kills, match time, etc.); (4) game setting controls, such as system settings, shop, and gold coins. Furthermore, the controls displayed in the user interface may differ between games. Some games include a friend list control, allowing users to view information about added friends and perform actions such as chatting, visiting each other's homes, and deleting friends. Other games include quest-related controls, such as displaying a list of current quests, including main quests and side quests. These controls help users better manage and play the game.

[0014] In an optional implementation, the game scene screen is the screen corresponding to the virtual scene displayed on the terminal device. The game scene screen may include virtual objects such as game characters (such as controlled virtual characters, also known as player virtual characters), NPC characters (NonPlayer Characters), and AI (Artificial Intelligence) characters that execute game logic in the virtual scene. The game scene screen usually changes as the controlled virtual character moves.

[0015] The aforementioned virtual scene is the content displayed (or provided) by the game application when it runs on a terminal or server. Optionally, the virtual scene is a simulation environment of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. The virtual scene can be any of a two-dimensional virtual scene, a 2.5-dimensional virtual scene, or a three-dimensional virtual scene. The virtual environment can be sky, land, ocean, etc., where the land includes environmental elements such as deserts and cities. Among them, a virtual scene is a scene containing the complete game logic of virtual objects controlled by the user. For example, in a sandbox-style 3D shooting game, a virtual scene is a 3D game world used by players to control virtual objects in battle. Instances of virtual scenes can include at least one element among mountains, plains, rivers, lakes, oceans, deserts, skies, plants, buildings, and vehicles. For example, in a 2D or 2.5D card game, a virtual scene is a scene used to display and release cards or display the virtual objects corresponding to cards. Instances of virtual scenes can include arenas, battlegrounds, or other "field" elements or other elements that can display the card battle status. For 2D or 2.5D multiplayer online tactical competitive games, a virtual scene is a 2D or 2.5D terrain scene used by virtual objects in battle. Instances of virtual scenes can include elements such as canyon-style mountains, lines, rivers, classrooms, desks and chairs, and podiums.

[0016] The aforementioned virtual object refers to a controllable dynamic object within a virtual scene. Optionally, this dynamic object can be a virtual character, virtual animal, anime character, etc. This virtual object is a character controlled by the player through an input device, or an AI character trained and set up for battle in a virtual environment, or an NPC set up for battle in a virtual scene. Optionally, this virtual object is a virtual character competing in a virtual scene. Optionally, the number of virtual objects in the virtual scene battle is preset or dynamically determined based on the number of clients joining the battle; this disclosure does not limit this. In one possible implementation, the user can control the virtual object to move within the virtual scene, for example, controlling the virtual object to run, jump, crawl, etc., and can also control the virtual object to use skills, virtual items, etc., provided by the application to fight against other virtual objects.

[0017] The method in one embodiment of this disclosure can be run on a terminal device or a server. The terminal device can be a local terminal device, such as a touch device or a non-touch device. When the method of the embodiment is run on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and client devices.

[0018] In an optional implementation, cloud gaming can run under a cloud interactive system. Cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operation mode, the game program and the game screen presentation are separate. The storage and operation of the method in this embodiment are completed on the cloud gaming server. The client device is used for receiving and sending data and presenting the game screen. For example, the client device can be a display device with data transmission capabilities close to the user, such as a mobile terminal, television, computer, or PDA; however, the terminal device for information processing is the cloud gaming server in the cloud. When playing the game, the player operates the client device 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 interface and other data, returns it to the client device through the network, and finally, the client device decodes and outputs the game interface.

[0019] In an optional implementation, the terminal device can be a local terminal device that stores the game program and is used to present the game interface. The local terminal device is used to interact with the player through the game interface; that is, it typically downloads, installs, and runs the game program via an electronic device. The local terminal device can provide the game interface to the player in various ways, such as rendering it on a terminal's display screen or providing it to the player via holographic projection. For example, the local terminal device can include a display screen and a processor. The display screen is used to present the game interface, which includes game scene visuals, and the processor is used to run the game, generate the game interface, and control the display of the game interface on the display screen.

[0020] According to one embodiment of the display control method of this disclosure, a graphical user interface is provided through a terminal. The graphical user interface displays at least a portion of a virtual scene, the virtual scene including a controlled virtual character, such as... Figure 1 As shown, the method may include: Step S110: Display a map interface through a graphical user interface. The map interface is used to display the area information of the virtual scene and includes a first location marker, which is used to identify the position of the controlled virtual character in the virtual scene. Step S120: In response to the instruction to specify a target location in the map interface, a virtual observation point is determined in the virtual scene; Step S130: Based on the relative positional relationship between the virtual observation point and the controlled virtual character, control the display of the preview screen. The preview screen is rendered based on the virtual camera parameters, which include the gaze direction, which originates from the virtual observation point and faces the controlled virtual object.

[0021] The method provided in this embodiment enables players to view a map interface containing regional information and a first location marker using the graphical user interface provided by the terminal. Players can actively issue specified commands to the target location to establish a virtual observation point in the virtual scene. Based on the relative positional relationship between the virtual observation point and the controlled virtual character, players can control the virtual camera to point from the virtual observation point towards the controlled virtual character. Thus, players can intuitively check the exposure status of their own model behind cover on their local terminal without relying on the perspective of teammates or enemies, reducing the frustration caused by misjudgments due to blind spots and significantly improving the interactivity and immersion of players during tactical concealment. Simultaneously, in addition to conventional first-person combat gameplay, a map-triggered external self-checking and observation mechanism is introduced, expanding the tactical verification dimension and enriching the layering of game content and the space for strategic choices. Furthermore, it helps reduce the repeated rendering requests caused by users frequently adjusting character positions to confirm model occlusion status, reducing terminal data processing pressure and rendering resource consumption, and improving the accuracy of occlusion judgment and human-computer interaction efficiency.

[0022] The embodiments of this disclosure will now be further described.

[0023] In an optional implementation, a graphical user interface (GUI) is provided via a terminal. The GUI displays at least a portion of the virtual scene, which includes a controlled virtual character. This provides players with an immersive visual interaction interface for the virtual scene and offers a unified digital presentation medium for subsequent map access and preview rendering.

[0024] Optionally, the aforementioned controlled virtual character is a virtual combat unit controlled by the current player, including the character's body and the weapon model it holds, used to perform tactical actions such as movement in the virtual scene.

[0025] Optionally, the aforementioned controlled virtual character can specifically manifest as a virtual soldier, virtual agent, or virtual athlete that the player controls in real time via an input device. Its posture can include standing, crouching, and crawling. In one embodiment, the controlled virtual character is presented in a first-person perspective within the graphical user interface of the player's device. The player can directly observe the partial model of the weapon held by the character and its arm movements, but it is difficult to accurately judge the character's full outline and the extent of weapon exposure from a conventional perspective. Furthermore, when the player controls the controlled virtual character into observation mode, the character becomes the focal point of the preview screen. The system can render the complete model of the character from the virtual observation point, allowing the player to intuitively determine the obstruction effect of cover on the character. It should be noted that the specific type of appearance, equipment, and props held by the controlled virtual character does not affect the implementation of the above observation mechanism. The character can wear different camouflage clothing or be equipped with weapons of different lengths; this embodiment does not limit this.

[0026] In step S110, a map interface is displayed through a graphical user interface. The map interface displays regional information of the virtual scene and includes a first location marker, which identifies the position of the controlled virtual character within the virtual scene. This allows players to readily grasp their location and orientation within the virtual scene using the map interface, providing an intuitive reference for quickly designating observation points and previewing exposure conditions. This significantly improves the convenience and accuracy of self-checking operations behind cover.

[0027] In one implementation, when the player controls the virtual character to move behind cover and conceal themselves, clicking the map control (such as the minimap) in the graphical user interface triggers the display of the map interface. This map interface appears as a semi-transparent pop-up overlaying the main screen, fully displaying the area information of the current virtual scene, such as terrain undulations, building distribution, and road directions. Simultaneously, a dot-shaped first location marker with an arrow tip is displayed in the lower center of the map interface. This first location marker, highlighted in a prominent color, indicates the current position of the controlled virtual character in the virtual scene in real time, allowing the player to quickly compare their own position with the surrounding environment.

[0028] Optionally, the map interface is used to present the spatial topology of the virtual scene and supports triggering observation modes. Its form can be dynamically adjusted according to operational needs. Optionally, the map interface can be a two-dimensional thumbnail generated in real time based on the current virtual scene, or a three-dimensional terrain projection map with high grayscale indicators. Its specific rendering accuracy can be dynamically adjusted according to the graphics processing capabilities of the terminal device. It should be noted that the form of the map interface is not limited to a fixed-size rectangular panel. It can be a semi-transparent floating window covering the main screen, a corner navigation page embedded in the edge of the graphical user interface, or a directional guide wheel displayed in the form of a compass. One purpose of this embodiment is to allow players to obtain a global orientation without completely leaving their current combat field of view by spatially reusing the map interface and the main screen. On the other hand, it also provides an accessible interactive base for quickly designating virtual observation points in the minimap. For example, in a first-person shooter match, when the player clicks the preset minimap activation button, the map interface occupies approximately one-quarter of the right side of the screen with a sliding animation from left to right. Its background is treated with 45% transparency, and the map displays the terrain framework, cover outlines, and their relative positions from a top-down perspective. Furthermore, the map interface can initially be anchored to the controlled virtual character, with a highlighted dot rendered at the corresponding coordinates as the primary location marker, allowing the player's gaze to quickly focus on their position. It should be noted that the above-described map interface presentation style is merely an example, and this disclosure is not intended to limit it. In actual implementation, it can be flexibly designed according to the game genre and human-computer interaction specifications.

[0029] Optionally, in addition to being manually activated by the player using dedicated controls (such as clicking the minimap), the map interface can also be automatically triggered and displayed when specific conditions are met, reducing the burden on players searching for controls. As one possible implementation, when the system detects that the controlled virtual character has entered the collision radius of cover and has remained in a crouching or prone position for more than a certain duration threshold, a map interface can be automatically generated on the graphical user interface and appear on the main screen with a semi-transparent, gradually appearing animation. Alternatively, the display of the map interface can be linked to the player's current weapon status. For example, when the player puts away their weapon and approaches the edge of cover, the map interface remains permanently in the lower left corner of the screen as a mini bar, which the player can click at any time to zoom in and view the full map. To avoid visual interference from automatic activation, if the system detects that the character is engaged in combat with enemy units or that the character's health is rapidly decreasing, the automatic pop-up of the map interface can be temporarily suppressed, thus maintaining the player's focus and clarity on the main screen. It should be understood that the triggering logic of the map interface has multiple branches, including manual triggering, automatic triggering, and semi-automatic triggering. These branches can be switched or combined according to the game difficulty mode, and this embodiment does not limit this.

[0030] Optionally, the first location identifier is used to mark the real-time location of the controlled virtual character in the map interface. Its shape can be a geometric shape and can change with the character's state.

[0031] Optionally, the first location marker can be in the form of a dot with a directional arrow, a diamond mark, a human silhouette, or a glowing pulse pin, etc. Its color can be a high-contrast fluorescent color scheme to maintain sufficient visual visibility against a multi-colored map background such as red, green, and blue. It should be noted that the first location marker not only statically indicates the current coordinates but can also rotate its attached arrow portion in real time according to the orientation of the controlled virtual character, thereby conveying additional spatial information about the character's facing direction to the player. In another embodiment, the display level of the first location marker can be configured to always float above the terrain layer in the map interface, and when the character moves, the first location marker updates its coordinates with a smooth interpolation animation, rather than undergoing abrupt teleportation jumps, thus improving the smoothness of the map interface. It should be noted that the size, color, and transparency values ​​of the first location marker described above are merely examples, and this disclosure is not intended to limit them. In other embodiments, any visual symbol conforming to different art styles can be used, as long as it can clearly indicate the current position of the controlled virtual character.

[0032] Optionally, regional information is used to convey spatial environment awareness, including terrain, cover, or passageways, and its precision can be adjusted according to the zoom level. Optionally, regional information may include, but is not limited to, one or more of the following in the virtual scene: terrain contour lines, surface material partitions, building outlines, fixed cover locations, traversable paths, and strategic resource markers. It should be noted that the display density of the above types of information is not fixed; it can be dynamically sampled and simplified according to the current zoom level of the map interface. For example, in global zoom-out mode, only the large terrain framework and main road directions are displayed, while in local zoom-in mode, the specific boundaries and height differences of individual covers are supplemented. One objective of this embodiment is to avoid information overload causing visual interference to the player's designated virtual observation point by rendering regional information of different precisions in layers on the map interface, while ensuring that the player has sufficient environmental detail support when precise judgment of cover occlusion relationships is required. For example, in a virtual scene depicting urban warfare, area information is presented in a line drawing style on the map interface. Low walls are outlined with solid gray lines, tall buildings are represented by dark gray filled blocks, and passable alleyways are marked with light blue thin lines. When the map interface responds to the player's zoom-in operation, the originally simplified building outlines are further marked with balconies, windows, and stairwell exits, allowing the player to more accurately predict the observation points that enemies might occupy. It should be noted that the specific rendering style of the area information described above is only an example, and this disclosure is not intended to limit it. In other embodiments, area information can also be expressed in the form of heatmaps, height cloud maps, or tactical grids.

[0033] In an optional implementation, the method further includes: controlling the display of directional markers in the map interface, wherein the directional markers are used to represent the direction of the view corresponding to the preview screen. Thus, by displaying directional markers in the map interface, players can intuitively establish the directional correspondence between the preview screen and the target location, quickly understand the source of the preview view, reduce the probability of directional misjudgment, and improve the efficiency of directional perception during cover self-checking. In one implementation, when a player selects to crouch in the corner of a building and opens the map interface during a game, they can long-press on a target location on the map where an enemy may be present to enter preview mode. At this time, a dotted line with an arrow appears between the target location and the first location marker where the controlled virtual character is located in the map interface; this dotted line is the directional marker, with its arrow pointing towards the player character, clearly indicating the direction of the virtual camera in the current preview window's view from the target location towards the player character, allowing the player to intuitively know the source direction of the preview view.

[0034] Optionally, directional markers are used to represent the direction of gaze in the map interface to establish a positional relationship between the virtual observation point and the controlled character. Optionally, directional markers can be graphical guidance elements, such as arrows pointing from a specified target location in the map interface to the controlled virtual character, dashed lines with arrows, or unidirectional line segments. They can also be presented in the map interface as a fan-shaped field of view or a ray. These directional markers can be directly overlaid on the map interface, forming a complete positional reference system together with the map's terrain information and the first position marker. The starting point of the directional marker corresponds to the coordinates of the target location on the map plane, while the ending point or pointing end corresponds to the first position marker of the controlled virtual character, thus completely mapping the direction of gaze from the target location towards the player character in the preview screen. During actual rendering, the color, thickness, or transparency of the directional markers can be dynamically adjusted according to the map interface's scaling to ensure good visual recognition at different display levels and avoid confusion with the map's inherent routes or boundary lines. It should be noted that the presentation form of directional markers is not limited to the above examples; any visual element that can convey a unidirectional gaze relationship in a two-dimensional map can be used.

[0035] Optionally, considering that the map interface may exhibit different interaction densities in different battle scenarios, the triggering logic for the directional indicator can also be configured to appear during the observation mode activation, or temporarily appear when the player performs a long press and fade out after releasing the press. To avoid the directional indicator obscuring the original map information, the directional indicator can be rendered semi-transparently, or it can be displayed using a color scheme with high contrast to the map background color, such as bright orange, fluorescent green, or lines with dynamic flowing effects.

[0036] In an optional implementation, when activating the observation mode, the method further includes: displaying at least one second location marker on the map interface, the second location marker representing a point that can trigger the generation of a virtual observation point. By presenting second location markers that can trigger the generation of virtual observation points on the map interface when the observation mode is activated, the player's aimless search for effective observation points can be significantly reduced, invalid touch operations can be decreased, and the triggering efficiency and interaction accuracy of the view self-check can be improved. In one implementation, when the player activates the observation mode by triggering the eye button on the edge of the map interface, several second location markers will automatically appear on the map interface at key terrain locations such as enemy-common attack routes, the outside of second-floor windows, and bomb site entrances. These markers are presented as diamond-shaped anchor points with dotted outlines, accompanied by miniature terrain symbols. When the player presses the touch focus on one of the second location markers, the system uses the map coordinates anchored to this marker as the virtual observation point, and renders a preview window pointing from that coordinate to the player's controlled virtual character in real time, allowing the player to intuitively judge whether their concealment behind current cover is sufficient to avoid enemy vision in that direction.

[0037] Optionally, activating the observation mode allows the map interface to switch to a state where specified virtual observation points are allowed, triggered by the mode switching control. Optionally, activating the observation mode is a prerequisite for the rendering and loading of the second location marker in the map interface. In other words, only after this mode is active will the system allow points meeting the virtual observation point generation conditions to be presented as second location markers. As a possible implementation, players can enter this mode by clicking the eye button at the edge of the map interface. At this time, the overall interactive context of the graphical user interface switches, and the touch semantics of the map interface change from regular coordinate browsing to observation point specification semantics. It should be noted that the trigger for activating the observation mode is not limited to a single button; it can also be configured as a shortcut gesture area, a designated key combination of game peripherals, or a voice command wake-up word, as long as a clear instruction to enter the observation mode can be sent to the system. In this mode, to ensure fairness, the system will simultaneously implement an information isolation strategy, automatically blocking real-time rendering data of enemy virtual characters and items, so that players cannot obtain additional battlefield information even in the preview view, thus ensuring that the existence of the second location marker does not disrupt the competitive balance of the game. It should be understood that the aforementioned active observation mode is fundamentally different from the regular spectator mode and death replay mode. Its design purpose is to help players verify the effectiveness of cover in first-person view from an external perspective, rather than to spy on enemy movements. In other words, active observation mode constitutes a key state hub connecting the map interface and the display logic of the second location marker. Without the activation of this mode, the second location marker will remain hidden to avoid visual interference with regular map browsing.

[0038] Optionally, the second location identifier is used to indicate points on the map interface that can trigger the generation of virtual observation points, and is distributed at key coordinates according to terrain features. Optionally, the above-mentioned second location identifier is configured to be overlaid on the map interface after the observation mode is activated, and its display logic is closely related to the terrain topology of the virtual scene. Specifically, the system can pre-place candidate points at tactically valuable terrain locations such as key path nodes, strategic high points, cover gaps, and areas where lines of sight intersect on the map. When the player enters the observation mode, these candidate points are activated and presented on the map interface in the form of second location identifiers. Considering that not all coordinates in the combat area are suitable as virtual observation points, as a possible implementation, the selection of the above-mentioned candidate points can be determined based on whether the point has an unobstructed line of sight towards the controlled virtual character. That is, if there is a continuous visible space between a point and the player's location, the second location identifier corresponding to the point is rendered as a highlight; otherwise, it is filtered out in grayscale or not displayed at all. To avoid visual congestion on the map interface due to excessive markers, the number and density of the aforementioned second location markers can be dynamically adjusted according to the current zoom level of the map interface. For example, when zooming out globally, only key points with global strategic significance can be displayed, while when zooming in locally, secondary points located at the edges of cover can be supplemented. One objective of this embodiment is to proactively expose effective observation points on the map interface, eliminating the need for players to blindly explore blank areas of the map. This significantly reduces the cognitive load and operational time required for players to find suitable virtual observation points, and also guides players to focus on those directions that truly pose tactical threats, thereby improving the targeting and efficiency of self-checking.

[0039] Optionally, the generation logic of the aforementioned second location markers can rely on pre-embedded static candidate points, or it can employ a dynamic calculation mechanism based on real-time game data or player behavior patterns. As one possible implementation, the system can calculate and generate temporary coordinates of deployable virtual observation points in real time based on the terrain openness within a certain radius around the controlled virtual character in the current game, and display these coordinates as second location markers on the map interface. For example, when a player is hiding behind a corner of a building, the system can automatically detect the windows, doorways, and the top edges of adjacent cover facing the enemy's attack direction, and generate these edge points that meet the line-of-sight conditions as second location markers. Furthermore, the visual presentation of these second location markers can be differentiated according to the priority of the points they represent. For example, second location markers closest to the player and proven by historical kill records to be high-threat pathways can be presented with a striking red pulse light effect, while general points that only meet the line-of-sight conditions but lack historical data support are marked with static blue dots. It should be understood that the aforementioned dynamic calculation process can be executed locally on the terminal to reduce screen latency, or it can be calculated by the server based on global terrain data and then distributed. In other words, this disclosure does not limit the data source and generation timing of the second location identifier, as long as it can represent the point on the map interface that can trigger the generation of a virtual observation point to the player.

[0040] In step S120, in response to a command specifying a target location on the map interface, a virtual observation point is determined in the virtual scene. This allows players to quickly establish an external observation point at the corresponding virtual scene coordinates simply by specifying the target location on the map interface, facilitating a convenient preview of the visibility of their own model and significantly reducing tactical frustration caused by misjudging concealment. In one example, after a player controls a controlled virtual character to crouch and conceal themselves behind a ruined wall and opens the map interface, they long-press on the target location on the map interface corresponding to a potential enemy high platform. Upon receiving this command, the system immediately maps the planar coordinates of the target location, combined with terrain elevation data, to three-dimensional spatial coordinates in the virtual scene, and determines a virtual observation point at these coordinates. This allows for the generation of a preview image based on the virtual observation point's line of sight towards the controlled virtual character, enabling the player to assess the adequacy of their model's concealment in that direction.

[0041] Optionally, the target location is used to identify candidate spatial points within the virtual scene on the map interface, serving as a mapping basis for subsequently determining virtual observation points. Optionally, the aforementioned target location can be any coordinate point manually selected by the player on the map interface, or it can be a candidate area pre-presented in the form of tactical markers on the map interface. As one implementation method, when a player controls a controlled virtual character to conceal themselves behind cover and intends to self-check their current posture, they can select a tactical key location on the map interface, such as a corner of a main road where the enemy might appear, a high window, or the edge of cover on the other side. After receiving the planar coordinate parameters of the target location, the system combines them with the terrain elevation data of the virtual scene to map them into three-dimensional spatial coordinates, and determines the arrangement of virtual observation points in the virtual scene based on these three-dimensional spatial coordinates. It should be noted that the selection of the target location is not limited to the aforementioned tactical hotspot areas, and can also be extended based on the warning markers of teammates or patrol points recommended by the system. This disclosure is not intended to limit the specific semantics of the target location. In practice, the map interface can use either a normalized coordinate system to record the target location or a grid number proportional to the world coordinates of the virtual scene to ensure that the positioning accuracy of the virtual observation point is consistent with the visual scale of the map interface.

[0042] Optionally, besides players selecting and determining the target location in real-time on the map interface, the system can automatically generate the target location after receiving the preset strategic marker voice analysis results, or players can specify it through gesture input, moving the cursor with a peripheral joystick, or other interactive methods. Furthermore, considering the impact of different map scales on the accuracy of point locations, a terrain height adaptive compensation mechanism can be introduced during the conversion of the target location from two-dimensional planar coordinates to three-dimensional coordinates in the virtual scene. This means that the target location is vertically corrected based on the ground elevation, building roof elevation, or bunker surface elevation of the current location in the virtual scene. For example, when the target location is selected above the roof of a building, the system can set the virtual observation point to an aerial coordinate slightly above the roof rather than a roof planar coordinate, thereby preventing the virtual observation point from being trapped inside the physical model or floating too high due to simple planar mapping, ensuring that the line of sight in the subsequent preview screen highly matches the actual enemy's field of vision environment. It should be understood that the threshold for the above height compensation can be configured differently according to the scene type, and this disclosure does not limit it.

[0043] Optionally, a specified instruction can be used to receive player interaction triggers at target locations in the map interface, in order to establish a virtual observation point at the corresponding coordinates in the virtual scene.

[0044] Optionally, the specified instruction can be a trigger signal generated by a long press, press, or double-click operation received through the touchscreen, or a trigger signal generated by a mouse click, right-click selection, or keyboard shortcut activation received through an external input device. Specifically, when a player presses a target location with their fingertip on the map interface for more than a preset duration, the terminal determines that the long press operation is successful and sends a specified instruction to the system. This specified instruction includes at least the coordinates of the target location on the map interface and an operation type identifier, so that the system can accurately distinguish between a preview request to enter observation mode and a normal map browsing request. Considering the error tolerance requirements of players in intense combat environments, the preset duration can be dynamically adjusted according to the player's operating habits or the state of the battle, for example, set to any value between 300 milliseconds and 800 milliseconds, thereby effectively reducing screen flickering and operation interference caused by frequent entry into observation mode due to short-term accidental touches.

[0045] Optionally, during the long-press operation, players can also perform a drag operation consecutively with the long press. In this case, the specified command can further include a coordinate sequence that updates continuously along the drag trajectory. The system analyzes the new target location in real time based on this coordinate sequence and simultaneously updates the position of the virtual observation point in the virtual scene, enabling real-time sweeping and seamless switching of the preview view. Furthermore, to avoid target location selection deviations due to finger obstruction or cursor exceeding the boundary when players initiate specified commands at the edge of the map interface, the map interface can automatically pan or partially zoom towards the center of the screen when it detects a displacement operation approaching the display boundary, thus reserving sufficient interactive space for drag operations. It should be understood that the triggering logic of specified commands can also be configured to only take effect when the controlled virtual character is under cover or crouching and stationary, reducing the risk of players being distracted by screen switching due to accidental triggering of the observation mode during movement and combat, and improving the certainty and safety of operations.

[0046] In an optional implementation, the specified instruction is generated by a long press operation targeting a target location; the method further includes: in response to the end of the long press operation, controlling the cancellation of the preview screen display. This allows players to instantly control the display of the preview screen through the natural interaction of pressing and releasing, avoiding the window from obscuring the map for extended periods and improving the ease of cover detection. In one implementation, when a player presses and holds their finger on a location on the map interface where an enemy is expected to appear, the system recognizes this long press operation targeting the target location, generates a specified instruction to determine a virtual observation point, and displays a preview screen on one side of the interface; when the player's finger leaves the screen, the system, in response to the end of the long press operation, immediately controls the cancellation of the preview screen display, restoring the original display state of the map interface.

[0047] Optionally, the long press operation is used to generate a specified command for a target location in the map interface to trigger the continuous display of the preview screen. Specifically, the long press operation can be an interactive action where the player presses their finger on the target location in the map interface and maintains it for a set duration. This set duration aims to distinguish between a player's single-click browsing intention and continuous observation intention in the map interface, preventing unnecessary switching of observation modes due to accidental touches. Considering the accuracy of touch recognition, this duration threshold can be configured to any value between 500 milliseconds and 1500 milliseconds. Furthermore, the system can start the timer the moment the finger touches the screen. Even if the player's hand slightly shifts before reaching the threshold, as long as the shift does not exceed the preset pixel tolerance range, the long press state can still remain valid. After the long press operation takes effect, the system maps a virtual observation point in the virtual scene based on the target location and renders a preview screen pointing from that observation point to the controlled virtual character in real time. In other words, the long press operation not only serves to trigger commands, but also maintains the continuous display of the preview screen by keeping the press state active, allowing players to stably observe their cover situation without having to trigger the hold control.

[0048] Optionally, in addition to a simple long press on the touchscreen, the aforementioned long press operation can also include a press operation triggered by the player applying pressure exceeding a pressure threshold and holding it for a certain duration on a device with pressure-sensitive recognition capabilities; or, in a game platform using an external controller, the long press operation can be mapped to a prolonged press on a designated button. As a possible implementation, during the press, the system can provide slight vibration or sound feedback in the graphical user interface to indicate that the long press has been recognized, thereby enhancing the certainty of the interaction.

[0049] Optionally, in response to the end of the long press operation, the system controls the cancellation of the preview display to terminate view rendering and restore the normal map display. Optionally, in response to the end of the long press operation, the process of controlling the cancellation of the preview display may include destroying or hiding the preview window and simultaneously stopping the real-time rendering pipeline of the corresponding virtual camera to release graphics processing resources. In one specific approach, the cancellation is not limited to immediate disappearance, but may be accompanied by a transition animation of a predetermined duration, such as gradually changing the window transparency of the preview from completely opaque to completely transparent within a range of 100 milliseconds to 300 milliseconds. It should be noted that the end event of this long press operation can be a touch release signal triggered by the player's finger leaving the touchscreen, or an equivalent interruption signal generated by the system due to abnormal touch interruption, forced game interface jump, or incoming call pop-up interruption. To prevent the preview screen from closing due to a slight touch interruption when it should not disappear, the above method may also include: if the touch signal is detected to be reconnected within a very short buffer window after the touch signal is lost, the display state of the preview screen is maintained without performing a cancellation operation, thereby improving the fault tolerance and stability of the interaction.

[0050] In an optional implementation, before the long press operation ends, the method further includes: controlling the updating of the virtual observation point's position in response to a drag operation continuous with the long press operation; and controlling real-time rendering and display of the updated preview screen based on the change in the virtual observation point's position. This allows players to switch between multiple observation points without repeated triggering, with the preview screen following the finger movement in real time, significantly improving the convenience and smoothness of the self-check operation behind cover. In one implementation, after entering observation mode, the player continuously presses and holds the first point on the map interface. At this time, a preview window pops up on the left side of the interface, displaying the view from the first point towards the player; then, without leaving the screen, the player drags their finger to the second point, and the image in the preview window smoothly transitions, displaying the view from the second point towards the player in real time; the preview window disappears when the player releases their finger.

[0051] Optionally, the aforementioned continuous dragging operation is used to receive single-finger swipe input on the map, so as to continuously change the position of the virtual observation point without interrupting the long press.

[0052] Optionally, the dragging operation that follows the long press is a sequence of swipe trajectories captured by the system's touch framework, provided the player's finger does not leave the touchscreen. Considering that players often need to quickly scan multiple potential threat directions when performing a self-check behind cover, as a possible implementation, the system can recognize the press state as a combined long press and drag gesture when it detects that the press duration exceeds a preset threshold and the press point has shifted. During this process, the map interface in the graphical user interface (such as the large map opened by triggering the minimap) remains in the foreground, and the preview window on the left side of the map interface does not close with the finger movement but updates in real time based on the swipe trajectory. In other words, players do not need to repeatedly perform independent click or long press actions for each observation point; they can complete the inspection of multiple external perspectives with just a single, continuous finger swipe. It should be noted that the above description of touch duration is only one example; in actual implementation, it can also be dynamically adjusted according to the device's touch sampling rate or the game's frame rate.

[0053] Optionally, the aforementioned virtual observation point position update is used to dynamically map the observation viewpoint in the virtual scene to a new spatial location based on the drag trajectory coordinates.

[0054] Optionally, the aforementioned control update of the virtual observation point's position can specifically include: converting the touch coordinates in the map interface into world coordinates in the virtual scene, and determining these world coordinates as the new virtual observation point. Considering that the map interface typically presents the global or local area of ​​the virtual scene in a top-down thumbnail format, as a possible implementation, the system can pre-establish a mapping relationship between the two-dimensional planar coordinate system of the minimap and the three-dimensional world coordinate system of the virtual scene. For example, when the player's finger slides from left to right on the map interface, the virtual observation point correspondingly shifts horizontally in the virtual scene, and the displacement ratio can be dynamically adjusted according to the zoom level of the map interface. That is, when the map interface is zoomed in, the same distance of finger sliding corresponds to a shorter world distance in the virtual scene, thereby achieving more precise fine-tuning of the observation point; when the map interface is zoomed out, the same sliding distance corresponds to a longer world distance, facilitating the player to quickly scan a large area. It should be noted that the height coordinates of the aforementioned virtual observation point can be kept consistent with the eye height of the controlled virtual character by default, or can be automatically adapted according to the terrain slope; this disclosure does not limit this.

[0055] Optionally, boundary constraint processing can be included during the virtual observation point position update process. Specifically, when the new position calculated based on the drag operation exceeds the currently displayed area of ​​the map interface, or corresponds to an inaccessible area in the virtual scene, the system can restrict the virtual observation point to the nearest legal boundary position to avoid camera clipping or rendering anomalies. Furthermore, to make the transition of preview screens more coherent and natural, the position change of the virtual observation point can be smoothly transitioned using linear interpolation or easing functions, rather than jumping directly to the target coordinates in every frame. For example, the system can perform interpolation calculations between the current observation point coordinates and the target coordinates according to a fixed ratio or a time function, so that the image in the preview window presents a camera panning visual effect. It should be understood that in scenarios where the finger slides quickly, the difference between the target coordinates and the current coordinates is generally large, so the interpolation speed can be increased accordingly; in scenarios where the finger makes slow, fine adjustments, the interpolation speed can be decreased accordingly to improve observation accuracy.

[0056] Optionally, the updated preview image is rendered in real time as the virtual observation point changes position, synchronously reflecting the visibility of the controlled virtual character as the observation point changes. Optionally, the real-time rendering and display of the updated preview image can include: recalculating the virtual camera parameters based on the new viewing direction in each frame or several frames where the virtual observation point's position changes, and calling the rendering pipeline to generate the corresponding preview image. Considering that the player's finger may be in a high-speed movement state during dragging, as a possible implementation, the system can dynamically adjust the rendering resolution based on the current frame rate and device performance. For example, when the device load is high or the finger movement speed is fast, the preview image can be temporarily rendered at a lower resolution, and then switched back to the normal resolution after the finger movement speed decreases or the device load decreases. In other words, this hierarchical rendering strategy can ensure the real-time follow-up of the preview and reduce input latency; on the other hand, it can avoid frame rate drops and device overheating caused by continuous full-resolution rendering. It should be noted that the dynamic adjustment of the rendering resolution is only an optional optimization method. On devices with sufficient performance, the preview image can also always be rendered in real time at a fixed high resolution.

[0057] Optionally, when generating the updated preview, in addition to redetermining the spatial position and viewing direction of the virtual camera, the rendering system can dynamically determine the display status of the controlled virtual character and scene elements based on preset visibility culling rules. Specifically, if part or all of the controlled virtual character's model is within the view frustum of the new observation point but is not visible in that direction due to cover obstruction, the preview will only display the cover portion, omitting the obstructed character limbs or weapon models. Furthermore, to maintain information isolation, even if enemy virtual characters or other dynamic objects exist within the view frustum of the new observation point, the aforementioned real-time rendering process always excludes them from the rendering list. For example, before submitting the drawing command, the rendering pipeline can query the object list of the current observation point and filter out all player-controlled objects that are not controlled virtual characters, thereby ensuring that the preview only presents the visibility relationship between the environment and the player's own model.

[0058] In an optional implementation, the method further includes: controlling a display mode switching control; activating an observation mode in response to a trigger operation on the mode switching control; and determining a virtual observation point in the virtual scene in response to a specified command for a target location on the map interface, including: in observation mode, determining a virtual observation point in the virtual scene in response to a specified command for a target location on the map interface. This limits the map-based virtual observation point determination function to being enabled only in observation mode, effectively avoiding accidental touches that interfere with regular interactions on the map interface, while ensuring that the view preview function is enabled only when the user has a clear intention, thus balancing operational convenience and game fairness.

[0059] In one implementation, when a player participates in a shooting game on a terminal and is hiding behind cover, a map interface can be brought up. The edge of this map interface displays an eye-shaped mode switching control. When the player clicks this control, the system activates observation mode, at which point the map interface's interaction logic changes. In activated observation mode, if the player long-presses a specified location on the map interface where an enemy might appear, the system determines a virtual observation point in the corresponding virtual scene and, based on the relative position of this virtual observation point to the controlled virtual character, controls the rendering of the preview screen. If the observation mode is not activated, and the player performs regular map browsing or point marking on the map interface, the virtual observation point determination process will not be triggered.

[0060] Optionally, the mode switching control is used to receive a trigger operation to activate the observation mode, thereby switching the map interaction to the observation preview state.

[0061] Optionally, the mode switching control can be an interactive element presented in various forms, at least partially including intuitive visual identifiers to allow players to quickly identify its function. In one implementation, the mode switching control can be represented as an eye-shaped button floating on the edge of the map interface, which highlights when selected by a triggered action. In another implementation, the mode switching control can also be embedded in the toolbar area of ​​the map interface, presented as an icon combined with a text label, such as displaying the word "Observe" or a telescope graphic. It should be noted that the above descriptions of the shape, position, and size of the mode switching control are only partial examples. In actual implementation, adjustments can be made according to the resolution of the terminal screen, the layout density of the map interface, and the player's custom settings. The purpose of this control is to logically isolate the regular browsing function and the observation preview function of the map interface through an explicit human-computer interaction entry point. On the one hand, this prevents players from triggering the view preview in an unexpected state, thus disrupting the normal game rhythm. On the other hand, it also requires explicit user confirmation to enable this function, thereby providing a prerequisite for subsequent information isolation design and view rendering.

[0062] Optionally, besides activating the observation mode via a click, the mode switching control can also respond to various trigger actions such as long press, double-click, or swipe. For example, using a long press for more than a preset duration can effectively reduce the probability of accidentally entering observation mode due to a single misclick; using a specific gesture trajectory (such as drawing a circle or checkmark in the control area) as the trigger action can further prevent accidental touches during regular operations. Considering the potential limitations in operational precision that players may face during intense matches, the mode switching control can also include a secondary confirmation mechanism when triggered, such as a brief confirmation pop-up requiring the player to confirm entering observation mode again. This prevents players from inadvertently entering a preview window that obstructs their view when urgently switching maps to check the battle situation, thus balancing the safety and responsiveness of the function trigger and making the interaction design more in line with the high-frequency, high-intensity operation requirements of shooting competition scenarios.

[0063] Optionally, the display state of the mode switching control can be dynamically linked to the real-time phase of the game. Before the first trigger condition is met, such as when the player has not yet entered a cover area or is currently in an open area, the mode switching control can be displayed in a semi-transparent or grayed-out form in a corner of the map interface, indicating to the player that the function is available but less necessary in the current scene; when the player enters a cover area or the system determines that the player is near a weapon model that may be exposed, the mode switching control can gradually become fully visible with a breathing light-like micro-animation, gently guiding the player to use the function. Furthermore, to prevent the control from occupying the display area for a long time and causing interface clutter, the control is completely hidden in the normal state when the player has not brought up the map interface; the control is only displayed for a preset period of time after the map interface is brought up. The dynamic switching of the above display parameters can not only reduce the visual interference of resident elements in the interactive interface to the player, but also provide just the right functional prompts when the player really needs to check the view.

[0064] Optionally, the observation mode is designed to limit the timing of virtual observation point determination, thereby restricting the effective scenarios of map interactions to the preview state.

[0065] Optionally, the observation mode is a local perspective self-checking state for a controlled virtual character. In this state, specified commands on the map interface no longer trigger regular map markers or coordinate broadcasts, but are instead remapped as commands to determine virtual observation points. When the observation mode is activated, the system immediately loads the virtual camera parameters related to the rendering of the preview screen and reserves a display space for the preview window in a local area of ​​the graphical user interface. In this mode, when the player executes a specified command for a possible target location of an enemy on the map interface, the system determines the corresponding virtual observation point in the virtual scene based on the target location, and renders the preview screen in the direction of the line of sight in real time based on the relative positional relationship between the virtual observation point and the controlled virtual character. It should be noted that the activation of the above observation mode can be a one-time continuous state or an instantaneous state for a single preview; this disclosure does not limit this. One purpose of this mechanism is to clearly distinguish between the regular map operation logic and the special self-checking observation logic at the program level by establishing an independent state identifier for the perspective preview function, preventing conflicts or overlaps between the two interactive behaviors at the event listening level.

[0066] Optionally, the observation mode can be a global state or a sub-mode specific to a particular map area or observation object. For example, in one implementation, the observation mode, once activated, changes the visual appearance of the map interface, such as subtly shifting the map background color or displaying specific lighting effects at the map edges, to indicate to the player that they are currently in a special observation state. Players can either choose a target location independently or execute specified commands on any blank point on the map, thus flexibly defining the observation direction and simplifying the operation path. In another implementation, the observation mode can be deeply integrated with an information isolation mechanism. Once the observation mode is activated, not only is the interaction logic of the virtual observation point enabled, but the system also automatically starts an object filtering process in the background to ensure that only the controlled virtual character is displayed in the preview screen while other player-controlled virtual characters are hidden. This design, which links the interaction entry point with the rendering filter, reduces the burden on players who need to trigger multiple function switches separately, and also makes the observation mode a unified logical entry point, carrying the entire chain of control from interaction triggering to screen presentation.

[0067] Optionally, considering the strict requirements for information fairness in shooting competitions, time or frequency limits can be imposed on entering and exiting observation mode to prevent players from abusing the function to gain an unfair advantage. For example, after a player activates observation mode once, the system can set a maximum duration, such as 10 or 15 seconds, after which the system will automatically exit observation mode and resume normal map browsing. Alternatively, a cooldown interval can be set between two consecutive activations of observation mode to prevent players from indirectly scouting enemy movements by frequently switching perspectives. Furthermore, during the observation mode, the system can pause some irrelevant actions of the controlled virtual character, such as reloading or throwing items, or block interface prompts unrelated to combat, allowing players to focus their attention on self-checking their perspective. If a player continuously drags the virtual observation point in observation mode for more than the preset time without releasing it, the system can trigger a timeout exit mechanism to forcibly close the preview screen, thereby preventing the function from being used to monitor specific areas for extended periods.

[0068] In an optional implementation, the mode switching control is displayed at the edge of the map interface. This placement of the mode switching control at the edge of the map interface reduces obstruction of core map information, allows players to quickly trigger the observation mode, and optimizes the interface layout and operational efficiency.

[0069] In one example, when the map interface is overlaid on the graphical user interface as a semi-transparent pop-up, the aforementioned mode switching control can be an eye-shaped touch button that floats above the upper right edge of the map pop-up. This eye button's placement close to the edge ensures that the large central display area of ​​the map pop-up remains clearly visible, showcasing terrain textures and location markers. This prevents the control from obstructing the main visual information of the map, thus ensuring that players can read the displayed area information on the map without obstruction while switching modes using this button.

[0070] Optionally, the aforementioned edge area is used to house the mode switching control, located on the periphery of the map interface display area. This is intended to reduce obstruction of the main map information and facilitate player activation. Optionally, the aforementioned edge area of ​​the map interface can be a peripheral area far from the geometric center within the overall map interface display area, such as at least one of the upper edge strip, lower edge strip, left edge strip, right edge strip, and a corner area formed by the intersection of these edges. Placing the mode switching control in these edge areas prevents it from floating or covering the center of the map interface, thus avoiding obstruction of key visual information such as the first location marker, terrain texture, or direction markers. This allows players to fully read the regional context of the controlled virtual character's current location after opening the map. As one possible implementation, the mode switching control can be a touch button with an eye icon. Its display size can adaptively scale according to the screen resolution and is constrained to the edge band area of ​​the map interface. Furthermore, this edge area can be differentiated from the interactive area of ​​the map interface by color or with a gradient of transparency, allowing players to intuitively identify the triggerable range of the control. This provides players with a low-cognitive-load mode switching entry point without affecting the density of the main map content. It should be noted that the above description of the specific location of the edge area is not exhaustive. In practical applications, the edge area can be dynamically configured on any side edge of the map interface based on the aspect ratio of the terminal screen, the player's left- or right-handed grip, and the landscape or portrait display format of the map interface, as long as it is outside the central display area of ​​the map. This disclosure is not limited to this.

[0071] In step S130, based on the relative positional relationship between the virtual observation point and the controlled virtual character, a preview screen is displayed. This preview screen is rendered using virtual camera parameters, including the line-of-sight direction, which originates from the virtual observation point and points towards the controlled virtual character. This locks the spatial logic between the observation point and the player, ensuring the preview screen accurately reproduces the enemy's potential perspective. This allows the player to accurately judge the exposure level of their model behind cover, effectively reducing the probability of unexpected deaths due to misjudgment caused by obstruction. In one implementation, the player-controlled virtual character hides behind containers in an abandoned warehouse. The virtual observation point is determined at a second-floor window where the enemy might appear, using the map interface. The system calculates the relative positional relationship between this observation point and the player character, and configures the virtual camera parameters accordingly, with the line-of-sight direction pointing from the second-floor window towards the player character. A preview screen is then generated through the rendering pipeline. In this preview screen, the player can clearly observe whether their character's legs are exposed beyond the edge of the container, thus confirming whether their current hiding position is safe from enemies at the second-floor window.

[0072] Optionally, the relative positional relationship represents the orientation and distance between the virtual observation point and the character, serving as the basis for determining the virtual camera's pose. Optionally, the aforementioned relative positional relationship can be quantified using position vectors in a three-dimensional spatial coordinate system. Specifically, the system can obtain the three-dimensional coordinates of the virtual observation point in the virtual scene's world coordinate system, and simultaneously obtain the three-dimensional coordinates of the controlled virtual character's current position, calculating the azimuth and distance values ​​between them based on these two coordinates. In one implementation, this distance value can be directly used to determine the spatial depth between the virtual camera and the controlled virtual character in the preview image; in another implementation, the azimuth information can be used to determine the virtual camera's horizontal orientation and pitch attitude. Thus, when the player specifies different virtual observation points in the map interface, the system can dynamically adjust the camera's external parameters required for rendering the preview image based on the real-time calculated relative positional relationship, ensuring that the preview image always presents the correct field of view from the specified observation point towards the player character.

[0073] Optionally, in practical applications, the aforementioned relative positional relationships, in addition to calculations based on absolute world coordinates, can also be supplemented by terrain height and cover surface normal information in the virtual scene for auxiliary correction. Considering that if the virtual observation point is located on a slope or a second-floor platform of a building, relying solely on the horizontal projection position may lead to a deviation between the line of sight and the player's expectations; therefore, the system can introduce ground height sampling and obstacle edge detection mechanisms when calculating the relative positional relationships to obtain more accurate observation point elevation and angle compensation. Furthermore, if there are penetrable vegetation or semi-transparent obstructions between the virtual observation point and the controlled virtual character, the aforementioned relative positional relationships can also be used to pre-calculate light transmittance or field of view occlusion ratio, thereby providing players with auxiliary prompts regarding exposure risks in the preview screen.

[0074] Optionally, virtual camera parameters control the viewpoint and range of the preview screen, including the gaze direction and the spatial pose of the observation point. Optionally, the virtual camera parameters may include attributes such as the virtual camera's position coordinates in three-dimensional space, orientation vector, field of view angle, and near / far clipping planes. In one example of this embodiment, the gaze direction, as a core component of the orientation vector, has its starting point set at the virtual observation point, while its ending point is locked at the center of the controlled virtual character's model or the head node. Based on this gaze direction and the spatial coordinates of the virtual observation point, the system can construct the external matrix of the virtual camera. When rendering the preview screen, the graphics engine multiplies this external matrix with a preset projection matrix to obtain the final view-projection transformation matrix, which then rasterizes the controlled virtual character's model and the surrounding scene geometry into the preview window. In this way, the field of view presented in the preview screen precisely corresponds to the enemy's perspective from the designated observation point, allowing the player to intuitively determine whether they are exposed.

[0075] Optionally, to ensure smooth rendering of the preview on different types of terminal devices, the virtual camera parameters can be adaptively adjusted according to the terminal's hardware performance and screen resolution. For example, on mobile terminals with limited graphics processing capabilities, the system can appropriately reduce the virtual camera's field of view or lower the rendering resolution of the preview to reduce the number of pixels and geometric batches processed per frame; while on high-performance terminals, a larger field of view and higher rendering precision can be enabled, and even dynamic shadows and ambient occlusion effects can be added. It should be noted that regardless of how the rendering quality is adjusted, the viewing direction always maintains the basic constraint of pointing from the virtual observation point to the controlled virtual character, thus ensuring smoothness of the image without sacrificing the accuracy of the viewpoint required for self-testing exposure judgment.

[0076] Optionally, considering that the enemy virtual character may be observing from various postures such as crouching, prone, or jumping in the scene, the gaze endpoint in the aforementioned virtual camera parameters can be dynamically bound to the skeletal nodes corresponding to different postures. Players can select different postures to simulate the enemy's field of vision when observing from a virtual observation point in different postures. For example, when a crouching posture is selected, the gaze endpoint can be moved down to the torso skeletal node to simulate the enemy's aiming baseline when observing from a crouching posture; when the player selects a prone posture, the gaze endpoint can be further moved down to a skeletal node close to the ground.

[0077] In an optional implementation, controlling the display of the preview screen includes: controlling the display of the preview screen in a window format within a partial area of ​​the graphical user interface. This overlay of a partial preview window onto the map interface allows players to intuitively observe their hidden status without completely obscuring the current main game screen and map information, balancing self-checking needs with situational awareness, and improving interactive convenience and the continuity of the gaming experience. In one implementation, when a player long-presses a target location in the map interface to enter observation mode, the system generates a floating window occupying approximately one-sixth of the screen area in the upper left corner of the graphical user interface. This window renders a third-person perspective view from the virtual observation point to the player character in real time, allowing the player to observe whether their model is completely obscured by cover. It should be noted that this window always floats above the main game screen, allowing players to simultaneously view self-check results and the battlefield environment without exiting the map interface, effectively reducing the sense of operational interruption caused by perspective switching.

[0078] Optionally, the preview screen can be presented in a window format to achieve layered overlay of the preview content and the main game screen without interference. Optionally, the preview screen window format can be one of a system floating window, an embedded panel in the interface, or a semi-transparent overlay. The size can be adaptively adjusted according to the terminal screen resolution and the current map interface's unfolded state. When the window is triggered to display, its edges can be configured as rounded rectangles or opaque borders to visually distinguish it from the background main game scene and prevent players from confusing the preview perspective with the real-time combat screen.

[0079] Optionally, to provide a self-check perspective without interrupting the player's main game progress, the aforementioned window format can be further configured as a floating ball that the player can freely drag or a collapsible tab that can automatically snap to the edge. When the player does not need to continuously observe, the window can be collapsed into a thumbnail icon located at the edge of the graphical user interface with a single click, and when the virtual observation point corresponding to the preview screen changes position, a breathing light or micro-motion effect will remind the player to expand it again for viewing. Furthermore, considering the screen size limitations of mobile terminals, the window can be placed by default in the visual blind spot between the virtual joystick and the shooting button, thereby maximizing the player's real-time observation and operation space of the battlefield environment while displaying self-check information.

[0080] Optionally, the preview screen can be controlled to be displayed in a partial area of ​​the graphical user interface to retain the remaining visible information of the main interface. Optionally, the aforementioned partial area can be a fixed display position at the edge of the map interface, an overlay area in the corner of the main game screen, or a floating window area that is semi-transparently overlaid on the map pop-up window; the specific location can be dynamically determined according to the current layout of the graphical user interface. For example, when the right sidebar of the map interface is expanded, the preview window automatically avoids rendering in the blank area on the left to prevent interface overlap with map function controls or direction indicators; during the display of the preview screen, the original interface content in this area can be partially obscured or compressed and rearranged to ensure that the player can simultaneously obtain map location information and self-test view within a single screen, thereby taking into account the need for parallel viewing of multi-source information.

[0081] In an optional implementation, the method further includes: when displaying a preview screen, controlling the hiding of virtual characters controlled by other players besides the controlled virtual character in the preview screen. This way, by hiding virtual characters controlled by other players in the preview screen, the real-time position information of the enemy or friend can be avoided from being exposed in the self-test view, thereby eliminating the possibility of cheating by using the observation mode to see through walls and ensuring the fairness of the competitive game. In one implementation, when the graphical user interface already displays a preview screen from the virtual observation point towards the controlled virtual character, the system performs classification filtering on the rendering objects in the current virtual scene: the controlled virtual character and the static environment scene are included in the rendering process, while all virtual characters controlled by any other player in the current game are excluded from this rendering process and are not displayed in the preview screen. For example, in a first-person shooter competitive match, a player can activate the observation mode using the mode switch control in the map interface and long-press a target location on the map interface to generate a virtual observation point. The pop-up preview window will then show a third-person view of the virtual observation point facing the player's own position. If an enemy player's virtual character happens to be passing by in that observation direction, or a friendly player's virtual character is moving nearby, the preview will show the player's own controlled virtual character and weapon model, but will not display any visible elements of the virtual characters controlled by the other players, thus ensuring that the player cannot obtain additional battlefield information through the preview window.

[0082] Optionally, "virtual characters controlled by other players" refers to all virtual entities not controlled by the current player that need to be filtered and rendered in the preview screen, in order to implement an information isolation mechanism. Optionally, the aforementioned virtual characters controlled by other players may include, but are not limited to, virtual combat units controlled by enemy players and virtual combat units controlled by friendly players, encompassing all virtual entities with character attributes in the current match except for the controlled virtual character itself. It should be noted that this entity range is designed to ensure that when a player uses the preview screen to check their own concealment status, they will not be able to see the real-time spatial coordinates and movement status of any other participating party through that viewing angle. For example, in a team-based shooting game, when a player clicks on a target location on the map interface to generate a virtual observation point and invokes the preview screen, the system can automatically identify all character objects in the current virtual scene whose ownership is not that of the local player, and skip the rendering instructions for the corresponding mesh models and texture data of these objects during the rendering of the preview screen, making the aforementioned virtual characters controlled by other players invisible within the observation window. This invisibility refers not only to the visual disappearance of the main character model, but also extends to the weapon attachments, equipment appearance, and dynamic effects attached to the character, thus preventing the inference of other players' presence through indirect visual cues. In other words, this mechanism strictly restricts the output of visual information to the environment and the controlled virtual character itself by forcibly limiting the set of rendering objects in the preview screen.

[0083] Optionally, in addition to the aforementioned manually controlled virtual characters, the scope of the information isolation can be further extended to neutral virtual units controlled by the system, or functional virtual entities driven by scripts, to prevent players from obtaining the location information of non-player characters through the preview screen. Considering that the guarantee of fairness in the game needs to be sufficiently complete, as a possible implementation method, the aforementioned hiding control can be implemented using the visibility mask of the rendering layer: before generating the preview screen, all dynamic entities in the current virtual scene are traversed to determine their ownership and control attributes. If a virtual entity is detected that is not controlled by the player account corresponding to the current terminal, it is marked as invisible in the preview view. Furthermore, to avoid indirectly revealing hidden information due to occlusion culling or physical interaction effects, the system can also control and completely suppress the rendering output of light, shadow, sound, and projectiles emitted by such hidden entities. It should be noted that this disclosure does not limit the above-mentioned hiding operation to all virtual characters controlled by other players. In a simplified implementation, the system may also selectively hide virtual characters controlled by enemy players while retaining the visibility of friendly characters. However, for example, in pursuit of a higher standard of fairness, a strategy of hiding all characters is usually adopted.

[0084] Optionally, in implementing the above-mentioned hiding control of virtual characters controlled by other players, it is usually necessary to establish a reliable distinguishing identifier between the controlled virtual character and the other virtual characters, such as determining ownership based on the player's unique identity identifier or client session number. If a boundary situation occurs where the entity ownership status has not been synchronized due to network latency, the virtual entity without clear ownership can be included in the hiding scope by default to prevent any possible information leakage. Based on this, the rendering logic of the above-mentioned preview screen can specifically include: after the virtual camera completes the construction of the view matrix and projection matrix, and before performing scene culling, first querying the object control permission field in the scene graph or entity manager, and dynamically determining whether the corresponding virtual character enters the final drawing instruction queue based on the value of the field. It should be noted that the implementation of this hiding strategy is independent of the window form of the preview screen and the selection method of the virtual observation point. Regardless of whether the preview screen is presented in the form of a floating window or temporarily replaces the main view in full screen, the above-mentioned filtering mechanism for virtual characters controlled by other players can be effective, and this disclosure embodiment does not limit this.

[0085] According to one embodiment of the display control device of this disclosure, a graphical user interface is provided via a terminal. The graphical user interface displays at least a portion of a virtual scene, the virtual scene including a controlled virtual character, such as... Figure 2 As shown, the device may include: Display module 201 is used to display a map interface through a graphical user interface, wherein the map interface is used to display area information of the virtual scene and includes a first location identifier, wherein the first location identifier is used to identify the position of the controlled virtual character in the virtual scene; The determination module 202 is used to determine a virtual observation point in the virtual scene based on the specified command of a target location in the map interface; The generation module 203 is used to control the display of the preview screen according to the relative positional relationship between the virtual observation point and the controlled virtual character. The preview screen is rendered according to the virtual camera parameters, which include the line of sight direction, which starts from the virtual observation point and faces the controlled virtual object.

[0086] In this way, triggering virtual observation points and rendering preview images through the map interface helps reduce the repeated rendering requests caused by users frequently adjusting the character's position to confirm the occlusion status of the model, reducing the pressure on terminal data processing and rendering resource consumption, and improving the accuracy of occlusion judgment and human-computer interaction efficiency.

[0087] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0088] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0089] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0090] The following is a detailed reference. Figure 3 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0091] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0092] In particular, according to one embodiment of this disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this disclosure includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this disclosure.

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

[0094] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. 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, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0095] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure 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, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; 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.

[0096] Although embodiments of the present disclosure 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 the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A display control method, characterized in that, The method includes providing a graphical user interface via a terminal, the graphical user interface displaying at least a portion of a virtual scene, the virtual scene including a controlled virtual character, the method comprising: The graphical user interface displays a map interface, wherein the map interface is used to display the area information of the virtual scene and includes a first location identifier, wherein the first location identifier is used to identify the position of the controlled virtual character in the virtual scene; In response to a command specifying a target location in the map interface, a virtual observation point is determined in the virtual scene; Based on the relative positional relationship between the virtual observation point and the controlled virtual character, a preview screen is controlled to be displayed. The preview screen is rendered based on virtual camera parameters, which include a line of sight. The line of sight originates from the virtual observation point and is directed toward the controlled virtual object.

2. The method according to claim 1, characterized in that, The control of the preview screen includes: The control displays the preview screen in a window format within a local area of ​​the graphical user interface.

3. The method according to claim 1, characterized in that, The method further includes: When the preview screen is displayed, control the hiding of other player-controlled virtual characters besides the controlled virtual character in the preview screen.

4. The method according to claim 1, characterized in that, The specified instruction is an instruction generated for a long press operation on the target location; the method further includes: In response to the end of the long press operation, the preview screen is canceled from being displayed.

5. The method according to claim 4, characterized in that, Before the long press operation ends, the method further includes: In response to a drag operation that occurs consecutively with the long press operation, the position of the virtual observation point is updated. Based on the changes in the position of the virtual observation point, control the real-time rendering and display of the updated preview screen.

6. The method according to claim 1, characterized in that, The method further includes: In the map interface, the display direction indicators are controlled, wherein the direction indicators are used to represent the line of sight corresponding to the preview screen.

7. The method according to claim 1, characterized in that, The method further includes: Controls for switching display modes; In response to a trigger operation on the mode switching control, the observation mode is activated; The step of determining a virtual observation point in the virtual scene in response to a specified command for a target location in the map interface includes: In the observation mode, in response to a specified command for a target location in the map interface, a virtual observation point is determined in the virtual scene.

8. The method according to claim 7, characterized in that, When the observation mode is activated, the method further includes: At least one second location identifier is displayed in the map interface, which is used to represent the point that can trigger the generation of virtual observation points.

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

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

Images