Information processing method and electronic device

Abstract

The present disclosure provides an information processing method and an electronic device, the method comprising: controlling a first virtual role to enter a target protection state; determining a target relationship attribute between a second virtual role and the first virtual role; when the target relationship attribute is a first relationship attribute, a second terminal renders the first virtual role with first appearance data; and when the target relationship attribute is a second relationship attribute, the second terminal renders the first virtual role with second appearance data. In this way, by differentiating the rendering of the target appearance according to the target relationship attribute, the terminal in the state of not establishing a specified social relationship can mask the target appearance, and the terminal in the state of having established the specified social relationship can keep the display of the target appearance, which helps to meet the user's differentiated information display needs while reducing the occupation of system resources by the interactive signaling lacking expected feedback.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to information processing methods and electronic devices. Background Technology

[0002] In multiplayer online virtual scene applications, a consistent global rendering strategy is usually adopted to present the appearance information of virtual characters to various terminals. The rendering and display methods of character data corresponding to different terminals within the same scene are basically the same.

[0003] However, in the aforementioned technologies, since each terminal in the same scenario adopts an indiscriminate rendering and display strategy for appearance data, it is difficult to take into account the differentiated needs of different users for information exposure range. In addition, each terminal needs to load and maintain complete appearance rendering resources, which increases memory consumption and network transmission load. At the same time, the unified information display method is difficult to effectively convey the social intention status to other terminals, which makes it easy for the terminal to handle a large number of interactive signalings that lack expected feedback, increasing the pressure of concurrent processing. Summary of the Invention

[0004] This disclosure provides an information processing 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, an information processing method is provided, the method comprising: controlling a first virtual character to enter a target protection state, wherein the first virtual character is a virtual character controlled by a first terminal; determining a target relationship attribute between a second virtual character and the first virtual character, wherein the second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character; when the target relationship attribute is a first relationship attribute, the second terminal renders the first virtual character with first appearance data to obscure the target appearance of the first virtual character; when the target relationship attribute is a second relationship attribute, the second terminal renders the first virtual character with second appearance data to maintain the display of the target appearance of the first virtual character.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, comprising: a control module for controlling a first virtual character to enter a target protection state, wherein the first virtual character is a virtual character controlled by a first terminal; a determination module for determining a target relationship attribute between a second virtual character and the first virtual character, wherein the second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character; and a display module for rendering the first virtual character with first appearance data by the second terminal when the target relationship attribute is a first relationship attribute, thereby obscuring the target appearance of the first virtual character; the display module is further configured to render the first virtual character with second appearance data by the second terminal when the target relationship attribute is a second relationship attribute, thereby maintaining the display of the target appearance of the first virtual character.

[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, when executing the computer program instructions, implements any of the above-described information processing methods.

[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 information processing methods described above.

[0009] One embodiment of this disclosure provides an information processing method, including: controlling a first virtual character to enter a target protection state, wherein the first virtual character is a virtual character controlled by a first terminal; determining a target relationship attribute between a second virtual character and the first virtual character, wherein the second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character; when the target relationship attribute is a first relationship attribute, the second terminal renders the first virtual character with first appearance data to obscure the target appearance of the first virtual character; when the target relationship attribute is a second relationship attribute, the second terminal renders the first virtual character with second appearance data to maintain the display of the target appearance of the first virtual character. In this way, by performing differentiated rendering of the target appearance based on the target relationship attribute, terminals in a state without a specified social relationship can obscure the target appearance, while terminals in a state with an established specified social relationship can maintain the display of the target appearance. This helps to meet users' differentiated information display needs while reducing the processing load of terminals caused by indiscriminate loading and rendering of appearance data, and reducing the occupation of system resources by interactive signaling lacking expected feedback. 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 A flowchart illustrating an information processing method provided in one exemplary embodiment of this disclosure is shown. Figure 2 This diagram illustrates the structure of an information processing apparatus 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 information processing method of this disclosure, such as Figure 1 As shown, the method may include: Step S110: Control the first virtual character to enter the target protection state, wherein the first virtual character is a virtual character controlled through the first terminal; Step S120: Determine the target relationship attribute between the second virtual character and the first virtual character, wherein the second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character; Step S130: When the target relationship attribute is the first relationship attribute, the second terminal renders the first virtual character with the first appearance data to cover the target appearance of the first virtual character. In step S140, when the target relationship attribute is the second relationship attribute, the second terminal renders the first virtual character with the second appearance data to maintain the display of the target appearance of the first virtual character.

[0021] According to one embodiment of this disclosure, by performing differentiated rendering of the target appearance based on the target relationship attribute, terminals in a state where no specified social relationship has been established can obscure the target appearance, while terminals in a state where a specified social relationship has been established can maintain the display of the target appearance and perform status identification. This helps to meet users' differentiated privacy needs while reducing the processing load of the terminal caused by indiscriminate loading and rendering of appearance data, and reducing the occupation of system resources by interactive signaling that lacks expected feedback.

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

[0023] In step S110, the first virtual character is controlled to enter the target protection state, wherein the first virtual character is a virtual character controlled through the first terminal. In this way, by actively controlling the virtual character to enter the target protection state, not only is a state prerequisite provided for subsequent differentiated appearance rendering, but players can also flexibly switch the degree of information exposure according to social needs, effectively balancing personalized display and privacy protection.

[0024] In one implementation, a player controls a first virtual character via a first terminal to move around in public areas of a virtual social scene. When a player does not wish for their appearance details to be recognized by strangers, they can trigger the appearance management entry in the graphical user interface and select a specific virtual item wearing control in the opened appearance configuration panel. In response to this trigger, the first terminal sends a state switching request to the server and, upon receiving a state confirmation message from the server, immediately controls the first virtual character to enter a target protection state. At this time, the first virtual character's status identifier on the server side switches from normal social mode to privacy protection mode (i.e., target protection state), and its corresponding appearance rendering strategy changes from full display to controlled display. However, this state change itself does not affect the display of the first virtual character on the first terminal; it is only used by other terminals participating in the same virtual scene to read the status identifier in subsequent rendering processes to execute corresponding appearance occlusion logic.

[0025] Optionally, the target protection state is used to switch the appearance display rules of virtual characters, presenting image information in a differentiated manner to players with different relationship attributes.

[0026] Optionally, the target protection state can be triggered and represented by wearing specific virtual items. In one possible implementation, the graphical user interface of the first terminal is equipped with a state switching control (which can be displayed on the graphical user interface after the first virtual character wears a specific virtual item). Players can send a command to the system to enter the target protection state by triggering this control. Considering that in social game scenarios, players may temporarily need to reduce the degree of information exposure due to changes in the current environment or mood, by setting up a state switching mechanism that can be triggered with one click, on the one hand, players can quickly switch from daily social mode (also known as daily social state) to privacy protection mode (also known as target protection state), avoiding the sense of operation interruption caused by repeatedly searching for function entry points in the interface hierarchy; on the other hand, since this state is associated with specific virtual items, when entering the target protection state, the appearance model of the first virtual character can automatically load and wear a raincoat or other appearance components (i.e., virtual items), thereby visually conveying the boundary signal that they do not want to be disturbed to other players in the scene. It should be noted that the above-mentioned presentation forms of virtual props are merely exemplary. The visual representation of the target protection state can also be other forms such as head-mounted display effects, ambient particle light effects, or character outline glowing. This disclosure is not limited to these.

[0027] Optionally, in addition to manually triggering the state switching control to enter the target protection state, the system can also control the first virtual character to enter this state in response to the fulfillment of specified automatic conditions. For example, when it is detected that the first virtual character has been continuously in a densely populated area for more than a specified time (e.g., 5 minutes) and has not interacted with any other virtual characters during this period, the system can automatically push a state switching prompt; if the player does not refuse within the specified time, the first virtual character will be automatically placed into the target protection state. The introduction of the above-mentioned automatic triggering mechanism can reduce the risk of continuous exposure of personal information due to players forgetting to manually enable privacy protection, and also provides a convenient, hands-free path for players who wish to maintain a low level of social pressure in the long term. It should be understood that whether it is manually triggered or automatically entered, the underlying data markers of the target protection state remain consistent to ensure that the second terminal can accurately make appearance rendering decisions based on the state markers and target relationship attributes in subsequent steps.

[0028] Optionally, during the process of controlling the first virtual character to enter the target protection state, the server can perform state verification and synchronous broadcast operations to ensure the consistency of states across multiple terminals. Considering that the first virtual character may be rendered and displayed by multiple second terminals simultaneously, after the first terminal performs a state switch, the state change message (the message that the first virtual character changes to the target protection state) needs to be forwarded by the server to all second terminals within the scene whose display area includes the first virtual character. To avoid state asynchrony issues caused by network latency, the server can record a timestamp when receiving a state switch request and send the timestamp along with the state flag; each terminal uses the server's timestamp as the standard for determining the state's effectiveness during rendering. Furthermore, if the first virtual character is in the midst of certain specific interactive actions (such as performing scene animation or playing facial expressions) at the moment of state switch, the system can set a delay strategy to execute the appearance switch only after the action is completed, thereby preventing screen jumps or animation breaks caused by sudden appearance changes. In other words, the entry into the target protection state can not only be instantaneous, but can also be a smooth transition based on the virtual character's current action queue, network environment parameters, or priority rules, so as to balance the timeliness of privacy protection with the continuity of visual presentation.

[0029] Optionally, the first virtual character is controlled by a first terminal, and its appearance data includes the target appearance that can be occluded and basic identification information. Optionally, the first virtual character can be a three-dimensional digital character created and customized by a player through the first terminal, and its appearance data includes at least multiple dimensions of target appearance, such as facial appearance (e.g., facial contours and expression textures), clothing appearance (e.g., the combination of tops, bottoms, and shoes), and accessory appearance (e.g., headwear, back ornaments, and handheld objects). Considering that the key mechanism of this disclosure lies in the differentiated occlusion or retention of the above-mentioned target appearance based on the target protection status, the first virtual character, in addition to having renderable appearance attributes, can also carry character identification information (e.g., player nickname, user ID, or personalized signature), some of which can still be retained and displayed under the target protection status, so that unfamiliar players can make basic distinctions and positioning of different virtual characters without violating privacy boundaries. It should be noted that the modeling basis of the first virtual character can be a realistic, cartoonish, or abstract geometric humanoid model, or an anthropomorphic animal model or a mechanical armor model. This disclosure does not limit the specific art style of the first virtual character.

[0030] Optionally, the first terminal, used to receive player input and control the first virtual character, can be a smart computing device loaded with a game client. Optionally, the first terminal can be an electronic device capable of providing a graphical user interface and receiving player operation commands, such as a smartphone, tablet, personal computer, game console, or virtual reality headset. In one embodiment, the first terminal establishes a network connection with the server by running a game client program. Various touch, click, or gesture operations performed by the player on the graphical user interface are converted into control commands, which are then parsed by the logic processing unit of the first terminal and applied to the first virtual character. Considering that entering the target protection state requires active triggering by the player, the graphical user interface of the first terminal, in addition to displaying the main viewport of the virtual scene, also needs to integrate a state switching control. The layout of this control should be convenient for the player to quickly access without affecting the operation of the main scene. It should be noted that the first terminal and the second terminal can be the same or different in hardware form; for example, the first terminal can be a smartphone, while the second terminal can be a tablet, both connected to the same server and participating in the interaction of the same virtual scene through their respective client programs. The above description of the device type of the first terminal is only an example. Any intelligent computing device that has network communication capabilities and can load virtual scenes and render virtual characters can be used as the first terminal. This disclosure does not limit it.

[0031] In an optional implementation, controlling the first virtual character to enter the target protection state includes: responding to a trigger operation on a state switching control associated with the first virtual character, and controlling the first virtual character to enter the target protection state. In this way, by responding to a trigger operation on the state switching control to control the virtual character to enter the target protection state, players can conveniently enable or disable privacy protection functions according to real-time social needs, thereby reducing operational costs and enhancing their autonomy over the exposure of personal information. In one implementation, when a player does not want the first virtual character to continue exposing personal appearance information in a multiplayer scenario, they can directly trigger the state switching control associated with the first virtual character in the game's main interface, for example, by clicking the perpetually displayed don / take control switch (i.e., the state switching control); in response to this trigger operation, the terminal sends a state change request to the server and controls the first virtual character to switch from its current normal appearance to a masked appearance in the target protection state. This state switching control allows players to interact directly without navigating through multiple system menus, thereby shortening the path from generating a privacy protection intention to its actual implementation and improving the response speed of the state switching.

[0032] Optionally, the state switching control is used to receive player-triggered actions to control the first virtual character to enter the target protection state. Its presentation can be a virtual switch or a shortcut button. Optionally, the state switching control can include, but is not limited to, a persistent virtual switch in the graphical user interface, a floating shortcut button, or a wear option in the first-level entry of the character appearance interface. Its location can be fixed in the upper right corner of the game's main interface, or it can be customized to the lower left sidebar or other easily accessible locations according to player operating habits. Considering that players' need for privacy protection in public multiplayer scenarios is often sudden and immediate, deploying the state switching control in a persistent area that does not require navigating through multiple menus effectively prevents players from missing the switching opportunity due to scrolling through system menus, thus enabling a shorter operation path to transition from a normal social state to a target protection state. As a specific implementation, when a player clicks the control, the first virtual character can directly perform the wearing action and load the corresponding occlusion appearance components in the current game scene. Simultaneously, this wearing process can be observed in real-time by other players in the same scene, thus visually conveying the state change information synchronously and enhancing the sense of ritual and consensus during the state switching.

[0033] Optionally, in addition to supporting single-click triggering, the state switching control can also respond to different triggering methods such as double-click confirmation, long-press to bring up a submenu, or gesture swipe operations. This disclosure is not limited to these. Furthermore, the visual appearance of the control can dynamically change according to whether the first virtual character is currently in a target protection state. For example, it can be displayed as a semi-transparent donning / undressing icon in the normal state, and switch to a highlighted raincoat icon after entering the target protection state. This allows players to intuitively determine their current social exposure level without needing to access additional information, effectively reducing cognitive burden and improving the accuracy of state control.

[0034] In an optional implementation, the method further includes: the first terminal rendering the first virtual character with second appearance data to maintain the display of the target appearance of the first virtual character. This avoids negative impacts on the local visual experience caused by privacy protection status while ensuring the complete presentation of the character's appearance information from the first terminal's perspective, helping to maintain the player's self-image perception and visual consistency.

[0035] In one implementation, when the first virtual character enters the target protection state, the first terminal, while rendering the character locally, still calls the preset second appearance data to fully present the character's original clothing textures and facial features, thus maintaining the display of the target appearance. For example, this second appearance data can correspond to the character's complete material pack and model configuration information in a normal social state. When the graphics rendering module receives the local viewpoint drawing instruction, it directly loads the original texture resources and skeletal animation data based on this second appearance data, skipping the resource calling logic for occlusion replacement, thereby completely restoring the original appearance of the virtual character on the first terminal's display interface.

[0036] Optionally, the second appearance data can be understood as a complete set of appearance resources reserved under a target protection state (such as a privacy protection state). As a specific implementation, the aforementioned second appearance data may include all facial textures, body clothing meshes, and 3D models of attached decorations for the character in a normal social state. When the first terminal triggers local rendering under the target protection state, the graphics engine directly reads the material identifier and model number corresponding to the second appearance data, skipping the occlusion replacement logic pointed to by the first appearance data, thereby completely restoring the original appearance of the virtual character on the first terminal's screen. Simultaneously, the second appearance data can also be configured to be synchronously applied to second terminals with established specified social relationships, allowing friends to still see the character's true personalized image in multiplayer scenarios, and indicating the current target protection state with a status indicator. This setting ensures that the player's visual experience is not negatively affected by the privacy protection function, while also maintaining information transparency within close social circles.

[0037] Optionally, in addition to containing high-fidelity appearance resources of the character in normal social situations, the second appearance data can also dynamically load display content of different precision levels based on terminal performance or network bandwidth. For example, the aforementioned second appearance data can be divided into two subsets: a distant simplified model and a close-up refined model. When the camera position of the first terminal is far from the character, the system prioritizes rendering the distant simplified model with a lower polygon count to reduce local computational load. When the player zooms in on the character through interactive operations, the system automatically switches to the close-up refined model, which includes high-definition textures and complex lighting responses. It should be noted that the aforementioned near-far switching mechanism is independent of the occlusion scheme of the first appearance data; the first terminal will not incorrectly load occlusion resources facing strangers from any viewing angle. Furthermore, to balance rendering efficiency in multi-player simultaneous scenarios, the second appearance data can also adaptively disable lighting and shadow calculations for some non-critical effects, retaining only the basic shading and outline of the target appearance. This ensures the player's visual integrity while reserving more computational resources for the first terminal to handle scene interaction and network synchronization.

[0038] Optionally, the target appearance may include, but is not limited to, facial appearance, clothing appearance, and accessory appearance, used to represent the personalized visual image of the virtual character. Optionally, the target appearance should be preserved to the greatest extent possible in the local view of the first terminal, and it should at least include the virtual character's facial appearance, clothing appearance, and accessory appearance. Among them, the facial appearance is used to convey the player's personalized image settings and emotional expression, and may include, but is not limited to, the character's face shape, skin tone, facial feature textures, and dynamic skeletal driven deformation data; the clothing appearance is used to present the overall matching effect of the character's currently worn top, bottom, shoes, and coat; the accessory appearance is used to display decorative items such as pendants, headdresses, and back ornaments attached to specific skeletal points on the character's body. Considering that players still need to frequently check their own image on the first terminal to confirm their appearance status or to take screenshots for sharing while in target protection mode, the complete preservation of the target appearance in the local view can significantly reduce the cognitive dissonance caused by the incorrect obscuring of the appearance. In the actual rendering process, the graphics processing unit can load the facial texture layer, clothing material layer, and accessory model layer sequentially according to the subdivided resource index pointed to by the second appearance data, and drive the target appearance to update synchronously with the character's movements through a unified skeletal animation system. In other words, even if the first virtual character is in a state of protecting the target appearance from being obscured by the unfamiliar player, the first terminal still presents the original visual image to the player without replacement or downgrade through the standard rendering pipeline.

[0039] In step S120, the target relationship attribute between the second virtual character and the first virtual character is determined. The second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character. This dynamic identification of the target relationship attribute between the second and first virtual characters, triggering observation, provides a precise basis for subsequent differentiated rendering, ensuring that the privacy protection mechanism can adapt to observers with different social relationships, effectively improving the flexibility and scene coverage of privacy protection. In practical applications, when the first virtual character, wearing a designated item (such as a privacy protection item) and in a target protection state, appears in the scene presented by the graphical user interface of the second terminal, the second terminal first determines that the first virtual character is within its display range based on scene space coordinates. Then, the client corresponding to the second terminal sends a relationship query request to the server. The server compares the association records of the second and first virtual characters in the social network database and returns the result that no designated social relationship has been established to the second terminal. Based on this, the second terminal assigns the target relationship attribute between the two as the first relationship attribute, serving as the basis for determining subsequent rendering branches.

[0040] Optionally, the second terminal is used to carry the second virtual character and perform differentiated rendering, and its display range directly determines the trigger boundary for the target relationship attribute query. Optionally, the second virtual character can be any virtual image controlled by other players through their corresponding terminal devices in the current game scene. In a multiplayer online scenario, there can be one or more second virtual characters. When multiple second virtual characters are simultaneously located in the vicinity of the first virtual character, the second terminal corresponding to each second virtual character can independently initiate the aforementioned query and determination of the target relationship attribute. It should be noted that the relative positional relationship between the second virtual character and the first virtual character can be continuously changing. As long as the display range of the second terminal corresponding to the second virtual character contains the first virtual character at a certain moment, the process of determining the target relationship attribute for the first virtual character can be triggered. This disclosure does not limit the two to maintaining a stationary state within a fixed distance.

[0041] Optionally, the target relationship attribute is used to characterize the current state of the second virtual character and the first virtual character at the social association level, and it is dynamically assigned a value based on the social data returned by the server.

[0042] Optionally, the target relationship attribute includes at least a first relationship attribute representing that no specified social relationship has been established between the second virtual character and the first virtual character, and a second relationship attribute representing that a specified social relationship has been established between them. The specified social relationship can be a friend relationship, a mentor-apprentice relationship, or a relationship among members of the same community—a directed association actively confirmed by the player or recognized by platform rules. In a specific example, when the first virtual character wears a specified item and activates target protection, if the server finds that the unique identifiers of the second and first virtual characters do not exist in the same friend relationship table, the target relationship attribute is assigned the first relationship attribute, and the second terminal uses this to call the first appearance data to perform privacy masking rendering. Conversely, if the two are game partners with an established friend relationship, the second relationship attribute is assigned, and the original appearance of the first virtual character remains visible. It should be noted that the timing of the above relationship attribute judgment can be triggered the instant the first virtual character enters the display range, or it can be refreshed periodically at a preset time interval; this disclosure does not limit this.

[0043] Optionally, in addition to binary-based friend / non-friend determination, the logic for determining the target relationship attribute can also support more granular social hierarchy division. For example, it can be further divided into multiple relationship levels such as close friends, ordinary friends, blacklisted users, and strangers, with each level corresponding to a different appearance rendering strategy. To avoid screen flickering or judgment jitter caused by server query latency, the second terminal can maintain a relationship attribute cache table locally. When the first virtual character is detected within the display range, the local cache is queried first to quickly determine the initial value of the target relationship attribute, while an asynchronous verification request is sent to the server. If the verification result is inconsistent with the cache, the target relationship attribute is refreshed and the local cache is updated in a smooth transition, thereby ensuring the accuracy of the determination while maintaining the stability and consistency of the visual presentation.

[0044] Optionally, the second terminal is used to host the second virtual character and perform differentiated rendering. Its display range directly determines the trigger boundary for querying the target relationship attribute. Optionally, the second terminal can be a smartphone, tablet, personal computer, or virtual reality headset running a game client. Its hardware configuration and display parameters directly affect the rendering accuracy and range determination sensitivity of the first virtual character. In practical applications, the second terminal presents a 3D virtual scene to the player controlling the second virtual character through a graphical user interface. This display range typically corresponds to the view frustum of the virtual camera or a spherical trigger area set around the second virtual character. When the spatial coordinates of the first virtual character fall within this display range, the second terminal is considered to have met the query trigger condition for the target relationship attribute. It should be noted that, in addition to handling local rendering output, the second terminal also undertakes the functions of sending relationship query requests to the server, receiving appearance data packets, and performing real-time rendering pipeline switching. It is an indispensable multi-functional node in the entire privacy-preserving rendering chain.

[0045] Optionally, multiple first virtual characters in target protection states may exist simultaneously within the display range of the same second terminal at the same time. The second terminal needs to independently perform target relationship attribute queries and determinations for each first virtual character. Considering the network congestion and rendering frame drops that may be caused by batch queries, the second terminal can adopt a hierarchical processing strategy. For example, it can set the first virtual characters in the center of the field of view as high-priority immediate queries, and set the first virtual characters in the edge areas or fast-moving areas as low-priority delayed queries. This allows for reasonable allocation of the terminal's processing bandwidth and network request frequency while ensuring the accuracy of privacy rendering within the core field of view. Furthermore, when the second terminal detects that it is in a weak network environment or under high load, it can temporarily reduce the determination radius of the display range or extend the refresh cycle of the relationship attributes to prioritize the operation response speed of the locally controlled second virtual characters.

[0046] Optionally, the display range is used to define the virtual space area covered by the current graphical interface of the second terminal, serving as a spatial prerequisite for triggering the determination of target relationship attributes. Optionally, the display range can correspond to the visible area in the virtual scene determined based on the current position of the second virtual character. This area can be a regular geometric shape such as a circle, rectangle, or sector, or it can be an irregular boundary such as the visible area of ​​a view frustum or the actual visible area after terrain occlusion. In a specific implementation, the display range is configured as a spherical area with a radius of 30 meters centered on the second virtual character. The server only synchronizes the status data of other virtual characters within this spherical area to the second terminal, thereby reducing unnecessary data transmission. When the first virtual character wearing a specified item enters the area from outside the area, the second terminal detects that its coordinates fall into the display range and then initiates the query process for the target relationship attributes. It should be noted that the boundary determination of the display range, in addition to relying on pure spatial distance calculation, can also be supplemented by line-of-sight occlusion detection, scene partition numbering, or a player-defined privacy concern list. This disclosure is not limited to a single distance threshold determination mode.

[0047] In an optional implementation, the first relationship attribute indicates that no specified social relationship has been established between the second virtual character and the first virtual character; the second relationship attribute indicates that a specified social relationship has been established between the second virtual character and the first virtual character. In this way, by distinguishing whether a specified social relationship has been established, a differentiated privacy rendering strategy is achieved, ensuring that unfamiliar players cannot see the target's appearance, while friends can still identify the target, thus balancing privacy protection and social continuity.

[0048] For example, when the first virtual character has entered the target protection state and the second virtual character has not yet established a designated social relationship with the first virtual character, the server determines the target relationship attribute between the two as the first relationship attribute. Subsequently, when the second terminal renders the first virtual character, it replaces its original facial appearance and clothing appearance with the first appearance data to present a unified privacy-protected image. Conversely, if the second virtual character has established a designated social relationship with the first virtual character, the target relationship attribute is determined as the second relationship attribute. The second terminal renders the target appearance of the first virtual character completely with the second appearance data so that its friends can normally recognize its personalized image.

[0049] Optionally, the first relationship attribute corresponds to the state where no effective social link has been formed between the controller of the second virtual character and the controller of the first virtual character. In this state, the player on the second terminal has not added the first virtual character as a friend, and there is no bidirectional or unidirectional designated social relationship between the two. When the server receives a rendering request, it queries the social relationship database and returns a status code indicating that no relationship has been established, thereby instructing the second terminal to load the first appearance data. The purpose of this mechanism is that when the first virtual character actively enters the target protection state, the system automatically masks the target appearance of unfamiliar players who do not have social trust, preventing personal appearance information from being viewed at will in public scenes, thereby reducing the social pressure on introverted players and avoiding unnecessary approaching or disturbance. It should be noted that the determination of the first relationship attribute can be based on real-time relationship queries on the server side or on matching based on locally cached social lists. This disclosure does not limit the specific determination location and synchronization frequency.

[0050] Optionally, the state of not establishing a designated social relationship, as indicated by the aforementioned first relationship attribute, can cover various social disconnection scenarios. For example, two virtual characters may have never initiated any form of social interaction request; or they may have initiated a request but it was rejected or expired; or they may have established a designated social relationship but it was subsequently actively terminated. In any of these scenarios, the second terminal should render the first virtual character using the first appearance data to maintain consistency in privacy protection. Furthermore, if there are temporary team-ups or stranger-on-screen interaction mechanisms in the game scene, even if the second virtual character and the first virtual character are in the same task team or the same map area, as long as they have not established a designated social relationship, the determination result of the first relationship attribute will not change. This ensures that privacy protection strategies take precedence over temporary collaborative relationships, preventing players from being forced to expose their appearance information due to participation in public gameplay.

[0051] Optionally, the second relationship attribute is used to indicate that a specified social relationship has been established between the second virtual character and the first virtual character to maintain the normal display of the target appearance. Optionally, the second relationship attribute corresponds to the state where a valid social link has been successfully established between the controller of the second virtual character and the controller of the first virtual character. In this state, the player on the second terminal has added the first virtual character as a friend, or both parties have completed mutual confirmation through social requests. At this time, the server returns a status code indicating that a relationship has been established, instructing the second terminal to load the second appearance data and fully render the target appearance of the first virtual character. Considering that friends usually have a higher level of trust and social understanding, the identification of the second relationship attribute ensures that the personalized image of the first virtual character is still visible to friends after privacy protection is enabled, avoiding the inability of friends to recognize the identity due to complete obscuring, thus balancing privacy protection and the continuity of familiar social interaction. In other words, the second relationship attribute, as a switching condition between the first and second appearance data, ensures the accuracy of privacy protection and the friendliness of the social experience.

[0052] Optionally, a designated social relationship is a persistent trust link established between virtual character operators through the in-game social system, which includes at least types such as friend relationships, follow relationships, intimate relationships, or mentor-apprentice relationships. The establishment of this relationship typically requires a two-way interactive process where one party initiates an application and the other party accepts confirmation. For example, player A sends a friend request to player B, and after player B clicks the "agree" control in the graphical user interface, the server writes a relationship record between the two player accounts, thus completing the construction of the designated social relationship. In one implementation, the designated social relationship can be a two-way symmetrical friend relationship, where both parties are friends; in another implementation, the designated social relationship can also be a one-way asymmetrical relationship, such as a follower relationship or a blacklist exemption relationship. One objective of this embodiment is to use the designated social relationship as a watershed in the appearance rendering strategy, ensuring that the granularity of privacy protection matches the level of social trust. Strangers cannot cross the relationship boundary to obtain appearance information, while players within the trust circle enjoy normal visual recognition permissions.

[0053] Optionally, the establishment and termination of designated social relationships can be linked to the target protection status of virtual characters. To avoid relationship interruption due to accidental operations, when the first virtual character is in the target protection status, it can still normally receive friend requests or emoticon interactions from other virtual characters. However, the initiator of the request can only see the privacy-protected image rendered from the first appearance data (i.e., the first virtual character with the target appearance obscured) before the relationship is established. Furthermore, if the controller of the first virtual character subsequently terminates the designated social relationship with the second virtual character, the server can immediately update the relationship database and revert the target relationship attribute from the second relationship attribute to the first relationship attribute. The second terminal will automatically switch to the first appearance data the next time it renders the first virtual character, thereby achieving a dynamic closed loop for privacy protection. It should be noted that the storage of designated social relationships can be based on a relational database on a centralized server or on a distributed node cache; this disclosure does not limit this.

[0054] In step S130, when the target relationship attribute is the first relationship attribute, the second terminal renders the first virtual character using the first appearance data to obscure the target appearance of the first virtual character. In this way, by replacing the original target appearance with the appearance corresponding to the first appearance data from the perspective of an unfamiliar player, the scope of personal information exposure can be effectively narrowed. While maintaining basic identifiability, the public social pressure on introverted players is significantly reduced, and a unified visual consensus is established for social boundaries. In one embodiment, in response to the target relationship attribute being the first relationship attribute, the second terminal performs a rendering switch on the first virtual character in the graphical user interface. Specifically, the second terminal acquires the first appearance data, which is a standardized visual resource distinct from the second appearance data. During the rendering process, the second terminal covers the target appearance of the first virtual character with the first appearance data, for example, replacing the original clothing and accessory appearance of the first virtual character entirely with a uniform raincoat appearance component, thereby obscuring the personalized information in the target appearance. After the above rendering is completed, the first virtual character in the display interface of the second terminal presents a visual form standardized by the first appearance data, no longer exposing the detailed features of the original customized appearance.

[0055] Optionally, the first appearance data is used to perform masking or replacement processing on the target appearance of the first virtual character when the target relationship attribute is the first relationship attribute, in order to achieve privacy protection for unfamiliar players. Optionally, the first appearance data can be a privacy-protecting appearance resource preset for the perspective of strangers, and its specific implementation may include, but is not limited to, standardized character outfits, uniform masking textures, or simplified geometric models. In one possible implementation, the first appearance data is configured as a set of standardized target appearance components (such as a raincoat). This target appearance component covers the original target appearance of the first virtual character, so that the unfamiliar player's display interface no longer presents the facial appearance, clothing appearance, and accessory appearance that belong to personal personalized expression. It should be noted that the specific visual representation of the first appearance data can be flexibly adjusted according to the application scenario or game style. For example, in a fantasy-themed multiplayer online game, the first appearance data can be set as a uniform travel cloak and wide-brimmed hat combination; in another modern urban-themed social simulation game, the first appearance data can also be set as a uniform sports suit and helmet combination. The above description of the raincoat appearance components is only one example. This disclosure is not intended to limit the specific form of the first appearance data. In actual implementation, the design can be extended according to the product positioning or art style.

[0056] Optionally, besides replacing the entire appearance, the first appearance data can also achieve privacy protection through a combination of partial occlusion and material remapping. Considering that a completely uniform appearance may reduce the visual richness of the scene, as a possible implementation, the first appearance data can be configured to perform occlusion processing only on sensitive areas of the target appearance. For example, material replacement or transparency can be performed on the facial area and nameplate accessories, while the body outline and basic clothing can be preserved or faded. That is, when the second terminal renders the first virtual character, it replaces the facial texture with a neutral mask, hides highly recognizable accessories, and desaturates the bright colors of the original clothing to low-recognition solid colors. In this way, on the one hand, the probability of the first virtual character being quickly recognized by strangers can be reduced through the first appearance data, and on the other hand, the loss of character interactivity caused by excessive uniformity of appearance can be avoided, thus achieving a balance between privacy protection and scene visual diversity.

[0057] In an optional implementation, the second terminal renders the first virtual character using the first appearance data to obscure the target appearance of the first virtual character. This includes: the second terminal rendering a target appearance component for the first virtual character to obscure or replace the target appearance through the target appearance component. In this way, by obscuring or replacing the original appearance through the target appearance component, the social pressure on unfamiliar players can be reduced by unifying the virtual image, while also allowing the rendering results to be differentiated according to relationship attributes, thus balancing privacy protection and visual presentation flexibility.

[0058] In practical applications, when the first virtual character is already under target protection and no designated social relationship has been established between the second terminal and the first virtual character, the second terminal binds a target appearance component to the skeleton mounting point of the first virtual character during scene rendering. This target appearance component is, for example, a uniform raincoat model covering the whole body, with its mesh layer set on top of the original clothing appearance and facial appearance, thereby directly obscuring the original target appearance. It can also replace the material and texture resources of the corresponding parts, so that the first virtual character from the perspective of an unfamiliar player presents a consistent anonymous virtual image, effectively preventing the leakage of personalized appearance information.

[0059] Optionally, the target appearance component can be an additional visual unit covering the character, designed to occlude or replace the target appearance through layered overlay. Optionally, the target appearance component can be represented as a uniform raincoat adapted to the body shape of the first virtual character, configured to cover the character's original facial appearance, clothing appearance, and accessory appearance. In one implementation, when the first virtual character enters a target protection state, and the second terminal determines that it has a first relationship attribute with the first virtual character that has not established a specified social relationship, the second terminal attaches the raincoat model to the character's skeletal nodes during the scene rendering stage, placing its mesh layer above the original target appearance, thereby physically occluding the hairstyle, clothing texture, and facial features; simultaneously, the material parameters of the raincoat model can be set to a matte, opaque material to further prevent the leakage of underlying appearance information through light and shadow reflection. In this way, the first virtual character seen by unfamiliar players will no longer retain any personalized appearance features, but will instead present a standardized, anonymous image, thus establishing a clear and identifiable privacy boundary in multi-player public scenes.

[0060] Optionally, considering the differences in art style and performance requirements across different scenarios, the aforementioned target appearance component is not limited to a physical raincoat model; it can also be implemented as a partial occlusion or visual effect unit. For example, in one implementation, the target appearance component can be a hazy mask covering the character's face, or a hazy fog of light and shadow surrounding the character. Both can make the target appearance visually indistinguishable through semi-transparent or distorted rendering. Furthermore, the target appearance component can also be configured to directly replace the original character's materials and textures, temporarily switching the original high-precision facial and clothing textures to low-recognition, unified preset textures, thereby saving rendering calls while protecting privacy. It should be noted that regardless of whether an overlay component or a replacement material is used, the number, coverage area, and display form of the aforementioned target appearance components can be dynamically adjusted according to the rendering capabilities of the terminal device and the game type. This disclosure is not intended to exhaustively limit this.

[0061] In an optional implementation, the method further includes: when the first virtual character is in a target protection state and the target relationship attribute is a first relationship attribute, the second terminal retains the display of basic information of the first virtual character; wherein, the basic information includes at least one of the following: character outline information, character identification information, and character location information. In this way, while privacy masking is effective, necessary identifiable information output to unfamiliar observers is maintained, ensuring that the scene existence of the target object is not completely erased, and effectively avoiding the problems of location loss and object confusion caused by complete anonymization.

[0062] In one implementation, when the first virtual character activates the target protection state, if the second virtual character has not yet established a designated social relationship with it, the second terminal, when rendering the first virtual character, uniformly replaces its personalized facial appearance, clothing appearance, and accessory appearance with a preset standardized privacy appearance, while retaining the character's basic information for display. For example, the aforementioned basic information may include the character's basic body outline in the scene to avoid completely losing its physical presence; it may also include identification information above the character's head, such as a temporary number or neutral symbol generated by the system, to distinguish multiple characters in privacy protection states from each other; furthermore, it may include the character's real-time location information in the current game scene, such as location markers on a minimap or directional projections on the ground, thereby ensuring that unfamiliar players can complete basic observation, differentiation, and spatial positioning of the character without obtaining its personal privacy appearance.

[0063] Optionally, the above reservation is used to maintain the basic information in a continuous output state when the privacy appearance rendering is in effect, preventing it from being occluded or replaced along with the target appearance.

[0064] Optionally, the aforementioned retention operation can be implemented by performing independent output control on the data channels corresponding to the basic information during the pixel processing stage or the interface layer compositing stage of the graphics rendering pipeline, so that it is not affected by the switching of the target appearance data. Considering that in a unified character rendering process, appearance data (such as clothing textures and facial textures) and basic information (such as name tags and location icons) often share the same set of shading parameters or are bound to the same model node, if the aforementioned basic information is not explicitly retained, the basic information may be hidden along with it due to material replacement or overall model switching when the first appearance data is called. To avoid the aforementioned problem of being hidden along with it, the aforementioned retention operation can set explicit display flags for each sub-item of the basic information when receiving the rendering instruction of the first appearance data, or in a layered rendering architecture, elevate the basic information data to an interface layer independent of the character model for mounting and drawing. It should be noted that the specific implementation level of the aforementioned retention operation can be adaptively adjusted according to different terminal graphics interfaces, and this disclosure does not limit it in this way.

[0065] Optionally, the basic information is used to provide a minimum amount of identifiable data when the target's appearance is occluded, in order to maintain the basic presence identification function of the virtual character in a multi-person environment. Optionally, the above-mentioned basic information is configured to continue to be output from the perspective of the target observer corresponding to the first relation attribute, which is designed to balance the basic needs of privacy protection and scene interaction. Specifically, when the personalized appearance of the first virtual character (such as facial features, clothing texture, and accessories) is completely occluded or replaced, if the observer does not retain any identifiable clues, the character will be downgraded to an anonymous entity that cannot be distinguished or tracked in a multi-person scene, which will lead to confusion in functions such as collision detection, remote interaction pointing, and group management. To avoid the above problems, the above-mentioned basic information can be pre-stored in the attribute dataset bound to the character account on the server side, and extracted and pre-output when the second terminal executes the rendering process, to ensure that even in a highly anonymized privacy state, the virtual object still has the necessary physical boundary cues and basic distinguishability.

[0066] Optionally, the specific composition of the aforementioned basic information is not limited to the three types of information mentioned above; it can be dynamically expanded or simplified according to the needs of the actual application scenario. As a possible implementation, in game environments emphasizing spatial collaboration, the aforementioned basic information can be additionally configured to include the character's orientation or movement speed information, allowing other players to predict the anonymous character's movement trajectory. In social plaza environments emphasizing identity identification, the aforementioned basic information can be simplified to retain only character identification information. By assigning a unique temporary visual identifier to each character in a privacy-protected state, different individuals can be distinguished to the greatest extent possible without revealing their true appearance. It should be noted that the above description of the basic information is only one example, and this disclosure is not intended to limit the composition of the basic information. In actual implementation, it can be adaptively adjusted according to the gameplay type or privacy protection level requirements.

[0067] Optionally, the rendering logic for the aforementioned basic information can also establish a conditional mutual exclusion relationship with the occlusion logic of the target appearance, allowing the server to distribute rendering data packets differentially based on the target relationship attributes. Specifically, when the second terminal requests to load the image data of the first virtual character, the server first queries the social relationship attributes between the two. If it determines that it is the first relationship attribute, the server sends a combined data packet containing the first appearance data and basic information data to the second terminal. The first appearance data is used to render a uniform privacy-occluding appearance, while the basic information data is displayed as an independent layer or additional attributes. If the server determines that it is the second relationship attribute or detects that the first virtual character has exited the target protection state, it stops sending explicit identification elements in the basic information data and instead sends the complete second appearance data to restore normal rendering. Through the above differential distribution mechanism, the risk of privacy leakage caused by client-side local caching errors or rendering logic omissions can be effectively prevented, ensuring that the privacy protection strategy is rigidly enforced at the server level.

[0068] Optionally, the character outline information is used to represent the basic shape boundary of the virtual character, maintaining the character's physical space occupancy cues when the target's appearance is occluded. Optionally, the aforementioned character outline information can be specifically implemented as a visual representation of the virtual character's basic silhouette, head outline, or limb placeholder frames, which are presented on the second terminal's display screen during rendering in the form of low-recognition neutral colors or semi-transparent masks. Considering that in multiplayer game scenarios, completely erasing the character's shape would cause the virtual object to lose its visual reference for collision volume, making it difficult for surrounding players to determine whether it occupies limited space resources such as passageways, seats, or interactive props, the preservation of the aforementioned character outline information essentially provides cues for the virtual character's basic physical boundaries in three-dimensional space. As one possible implementation, the outline information can be simplified into a standard cylindrical or capsule-shaped placeholder with the same height as the original character model to ensure the accuracy of vertical space judgment, but its surface does not contain any personalized clothing textures or biological feature details; in other implementations, the outline information can also be implemented as a wireframe model scaled proportionally to the original character, visually indicating the presence of an interactive entity at that location by reducing the fill transparency, while avoiding exposing the real appearance.

[0069] Optionally, the aforementioned character identification information can be configured as a temporary visual symbol, sequential number, or neutral nickname tag dynamically assigned by the server. This identification information is directly rendered in the character name display area on the second terminal without being associated with real account data. Considering that when multiple players simultaneously enable target protection, if all characters present a completely identical privacy appearance and lack any distinguishing markers, observers will be unable to identify which anonymous entity has just issued an interaction request or performed an emoticon, leading to incorrect delivery of social feedback and target omission. To avoid this problem, the aforementioned identification information can be assigned a unique numerical number within the current scene session, for example, arranged sequentially in the form of numerical numbers; furthermore, the aforementioned identification information can also be implemented as a randomly generated graphic symbol or color code, allowing players to quickly establish a temporary cognitive mapping of the anonymous object within a short period. It should be noted that the aforementioned identification information only takes effect from the perspective of the observer with the first relationship attribute. Once the two parties establish a designated social relationship or the target protection state is lifted, the aforementioned temporary identifier is replaced by the real character nickname. In another possible implementation, the character identification information can also be the real character nickname of the first virtual character, so as to establish a basic degree of differentiation between different first virtual characters.

[0070] Optionally, character location information is used to inform observers of the virtual character's real-time spatial position in the scene, supporting basic orientation awareness and pathfinding interaction needs. Optionally, the aforementioned character location information can be implemented as dynamic coordinate points on a top-down minimap, directional guide lines on the scene ground, or vertical positioning markers above the character's head. The displayed content only reflects the virtual object's real-time spatial coordinates within the current level and does not include any trajectory history or behavior prediction data. Considering that in open multiplayer game maps, if a character in a privacy-protected state is completely invisible in space and lacks any location cues, other players may repeatedly initiate invalid interaction requests because they cannot identify the character's location, or find it difficult to confirm the actual distribution of teammates when performing area-of-effect cooperative gameplay. As a possible implementation, the aforementioned character location information can be displayed as high-contrast geometric shapes (e.g., blue triangles or green dots) on the minimap layer, and the display level of these geometric shapes is lower than that of regular teammate markers to avoid visual interference.

[0071] In optional implementations, the target appearance includes at least one of the following: facial appearance, clothing appearance, and accessory appearance. By subdividing the target appearance into facial, clothing, and accessory dimensions, the granularity of privacy-protecting information can be precisely defined, and differentiated masking can be implemented, balancing personalized expression with privacy security.

[0072] The following explanation uses a first virtual character in a target protection state as an example: In one implementation, when the first virtual character enters the target protection state, the second terminal, when rendering the character, will differentiate different appearance categories based on the target relationship attributes. For example, facial appearance can be represented by the virtual character's eyebrow and eye contours, skin texture, and facial markings, which can be replaced with a uniform, featureless basic mask in privacy protection mode; clothing appearance can be represented by a player-customized combination of tops, bottoms, and shoes, which can be automatically replaced with a default uniform protective suit; accessory appearance can be represented by the character's hat, back ornaments, and hand-held decorative props, which can be hidden by the system or replaced with unidentifiable basic accessories in the above state. It should be noted that the above three types of appearance can trigger occlusion simultaneously, or one or more can be partially retained according to system presets or player-customized configurations; this disclosure does not limit this.

[0073] In step S140, when the target relationship attribute is the second relationship attribute, the second terminal renders the first virtual character with the second appearance data to maintain the display of the first virtual character's target appearance. In this way, the player's target appearance is fully restored on the terminal side where social relationships have been established, effectively ensuring the continuity of identity recognition and interaction among friends in privacy-protected scenarios, and avoiding visual information gaps in close relationships.

[0074] In one implementation, when the system detects that a designated social relationship has been established between the second virtual character and the first virtual character (e.g., they are friends in the game), the second terminal carrying the second virtual character uses the second appearance data for rendering the first virtual character during the loading of scene characters. This fully restores the personalized features of the first virtual character, such as facial appearance, clothing appearance, and accessory appearance, in the display screen of the second terminal, ensuring that the operator of the second virtual character can clearly identify the other party's identity from the friend's perspective and normally initiate interactive operations such as facial expressions or scene graffiti.

[0075] In an optional implementation, the method further includes: when the second terminal renders the first virtual character using the second appearance data, displaying a status identifier for the first virtual character, wherein the status identifier indicates that the first virtual character is currently in a target protection state. This allows for the protection of player privacy while enabling those with established social relationships to promptly know the player's current social intentions, thus balancing privacy protection and relationship maintenance.

[0076] In one implementation, when the second virtual character and the first virtual character have established a designated social relationship, the second terminal generates a status indicator in a preset area above the character model, while fully displaying the original appearance of the first virtual character. The indicator is presented in the form of a light blue halo around the edge of the character's nickname, which is used to prompt the second virtual character that the first virtual character is currently in a target protection state and has a low willingness to socialize, so that the second virtual character can reasonably predict the other party's social boundaries before initiating further interactive behavior.

[0077] Optionally, the status identifier is used to convey the first virtual character's current social intention information to other objects in the virtual world (such as objects with whom social relationships have been established), and its presentation can take various visual forms.

[0078] Optionally, the presentation of the status indicator may include, but is not limited to, at least one of the following: particle lighting effects surrounding the character model, a graphic badge floating above the character's head, or a semi-transparent label displayed next to the character's nickname. For example, when the first virtual character is wearing a privacy protection nameplate (i.e., a designated virtual item) and is in a target protection state, the character's appearance remains normal from the perspective of their friend, but a visual cue with a soft glowing effect appears above the character's head; this visual cue is the status indicator. It should be noted that the purpose of the above status indicator design is to ensure that players in close social relationships can promptly know the other party's current status, avoiding unnecessary social friction caused by the other party's normal appearance but reduced willingness to interact. This status indicator exists in a non-intrusive visual form, conveying information to friends that the first virtual character is currently in a low-social-will mode without affecting the immersion of the scene. This allows friends to adjust their interaction strategies based on this signal, such as temporarily refraining from initiating complex team invitations or high-intensity real-time interaction requests, thereby balancing privacy protection and the harmonious stability of social relationships.

[0079] Optionally, considering the differentiated information prompts required in different game scenarios, the display position and triggering logic of the status indicator can be flexibly configured. As one possible implementation, the status indicator can always be displayed in the graphical user interface corresponding to the friend's perspective, remaining visible as long as the first virtual character is in a target protection state. As another possible implementation, to avoid information overload, the status indicator can also dynamically appear only after specific triggering conditions are met. For example, when the second virtual character's viewpoint is aligned with the first virtual character and remains there for more than a preset time, or when the second virtual character attempts to initiate a specific interaction command to the first virtual character, the system loads the status indicator near the first virtual character model. Furthermore, the visual parameters of the status indicator, such as transparency, color saturation, or dynamic flashing frequency, can be dynamically adjusted according to the duration the first virtual character is in a target protection state. The longer the duration, the lower the visual prominence of the indicator can be, thus reducing visual interference to friends during long-term gameplay. This on-demand display and dynamic decay mechanism ensures the effective transmission of social intention information at crucial moments while avoiding continuous visual pollution of the game screen.

[0080] Optionally, it should be understood that in a multiplayer interactive environment, the relationship attributes between the first and second virtual characters may change as the game progresses, and the display logic of the status indicators needs to be adapted accordingly. If the social relationship between the second and first virtual characters changes from unestablished to established, the rendering method of the first virtual character on the second terminal switches from the first appearance data to the second appearance data. At this time, the status indicator should be loaded and displayed in a timely manner to fill the gap in status perception that may occur after the appearance switch. Similarly, if the first virtual character actively removes the target protection status, the status indicator should be hidden simultaneously or a fade-out animation should be executed to prevent expired social intention information from being transmitted to friends due to residual indicators.

[0081] In an optional implementation, the method further includes: in response to detecting that the first virtual character is not currently in a target protection state, the second terminal renders the first virtual character with second appearance data to maintain the display of the target appearance of the first virtual character. Thus, by automatically restoring full appearance rendering when the first virtual character is not in a privacy protection state (i.e., not in a target protection state), undue interference of the protection mechanism with normal social interaction is avoided, while ensuring the identifiability of players in regular interactions and maintaining the smoothness of the social experience.

[0082] In one implementation, when the player controlling the first virtual character actively removes a designated virtual item using the donning / undressing controls in the upper right corner of the graphical user interface, the server immediately detects that the first virtual character is no longer in a target protection state. At this time, upon receiving a status synchronization message, the second terminal immediately terminates the call to the first appearance data and instead uses the second appearance data to fully render the full-body model of the first virtual character, ensuring that its facial appearance, clothing appearance, and accessory appearance are all drawn and output according to the original settings, thereby restoring the character's normal, recognizable style when privacy masking is not enabled. Optionally, not being in a target protection state indicates that the first virtual character has removed privacy masking and returned to a normal, recognizable social presentation mode.

[0083] Optionally, the specific implementation of the first virtual character not being in the target protection state can take several forms. For example, this state can be reflected in the state change triggered by the player actively removing a specified virtual item through the dressing / undressing control in the upper right corner of the graphical user interface, or it can be reflected in the temporary protection mark that is synchronously removed on the server side after the player turns off the privacy protection switch in the character dressing interface. In this case, regardless of the interaction entry point, once the state switching command is received, the server can detect and record in real time that the first virtual character is no longer in the target protection state, and then send an appearance restoration command to the second terminal whose display range includes the first virtual character. The purpose of this design is that when a player has the intention to actively socialize and chooses to remove the name tag, the system can promptly terminate the appearance masking strategy for unfamiliar players, avoiding the privacy protection mechanism from continuing to be effective in scenarios where players want to present themselves normally, thus preventing social obstacles. At the same time, the appearance data restoration rendering process can be triggered synchronously with the animation of the player removing the specified virtual item, without requiring the player to perform additional refresh or restart operations, thus making the transition from privacy protection mode to daily social mode smoother and more natural, reducing interaction costs and enhancing the immersive experience of virtual social scenarios.

[0084] Optionally, in other implementations, the aforementioned detection logic for not being in the target protection state can also be added to an automatic timeout mechanism or scene switching strategy, rather than being limited to the specific triggering path of players manually removing designated virtual props. For example, when the first virtual character enters a specific public activity scene, the system can by default require all participants to temporarily exit the target protection state to ensure sufficient activity interaction. At this time, the first virtual character can be configured to automatically not be in the target protection state within the scene, and the second terminal will then respond to the scene configuration and complete the rendering with the second appearance data; after the player exits the activity scene, the system can automatically restore its previous protection state setting. This scenario-based automatic detection and switching method can, on the one hand, quickly remove appearance occlusion in situations requiring high collaboration or display, ensuring visual information symmetry between players; on the other hand, it eliminates the need for players to manually adjust privacy settings one by one, effectively reducing repetitive operations and taking into account the differences in social openness in different game modes, thus expanding the adaptability boundaries of the state management mechanism.

[0085] An information processing apparatus according to one embodiment of the present disclosure, such as Figure 2 As shown, the device may include: The control module 201 is used to control the first virtual character to enter the target protection state, wherein the first virtual character is a virtual character controlled through the first terminal; The determining module 202 is used to determine the target relationship attribute between the second virtual character and the first virtual character, wherein the second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character; Display module 203 is used to render the first virtual character with the first appearance data when the target relationship attribute is the first relationship attribute, so as to cover the target appearance of the first virtual character. The display module 203 is also used to render the first virtual character with the second appearance data when the target relationship attribute is the second relationship attribute, so as to maintain the display of the target appearance of the first virtual character.

[0086] In this way, by rendering the target appearance differently based on the target relationship attributes, terminals in the state of not having established a specified social relationship can obscure the target appearance, while terminals in the state of having established a specified social relationship can maintain the display of the target appearance and display the status. This helps to meet users' differentiated privacy needs while reducing the processing load of terminals caused by loading and rendering appearance data indiscriminately, and reducing the occupation of system resources by interactive signaling that lacks expected feedback.

[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.

Claims

1. An information processing method, characterized in that, The method includes: Control the first virtual character to enter the target protection state, wherein the first virtual character is a virtual character controlled through the first terminal; Determine the target relationship attribute between the second virtual character and the first virtual character, wherein the second virtual character is a virtual character controlled by a second terminal, and the second terminal is a terminal whose display range includes the first virtual character; When the target relationship attribute is the first relationship attribute, the second terminal renders the first virtual character with the first appearance data to obscure the target appearance of the first virtual character; When the target relationship attribute is the second relationship attribute, the second terminal renders the first virtual character with the second appearance data to maintain the display of the target appearance of the first virtual character.

2. The method according to claim 1, characterized in that, The method further includes: When the second terminal renders the first virtual character with the second appearance data, it displays the status identifier of the first virtual character, wherein the status identifier is used to indicate that the first virtual character is currently in the target protection state.

3. The method according to claim 1, characterized in that, The control of the first virtual character to enter the target protection state includes: In response to a trigger operation on a state switching control associated with the first virtual character, the first virtual character is controlled to enter a target protection state.

4. The method according to claim 1, characterized in that, The method further includes: In response to detecting that the first virtual character is not currently in the target protection state, the second terminal renders the first virtual character with the second appearance data to maintain the display of the target appearance of the first virtual character.

5. The method according to claim 1, characterized in that, The first relationship attribute is used to indicate that no specified social relationship has been established between the second virtual character and the first virtual character; the second relationship attribute is used to indicate that a specified social relationship has been established between the second virtual character and the first virtual character.

6. The method according to claim 1, characterized in that, The method further includes: The first terminal renders the first virtual character with the second appearance data to maintain the display of the target appearance of the first virtual character.

7. The method according to claim 1, characterized in that, The second terminal renders the first virtual character using first appearance data to obscure the target appearance of the first virtual character, including: The second terminal renders a target appearance component for the first virtual character, so as to cover or replace the target appearance through the target appearance component.

8. The method according to claim 1, characterized in that, The method further includes: When the first virtual character is in the target protection state and the target relationship attribute is the first relationship attribute, the second terminal retains the display of the basic information of the first virtual character; The basic information includes at least one of the following: character outline information, character identification information, and character positioning information.

9. The method according to claim 1, characterized in that, The target appearance includes at least one of the following: facial appearance, clothing appearance, and accessory appearance.

10. 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 information processing method as described in any one of claims 1 to 9.

Images