Information processing method and electronic device

Abstract

This disclosure provides an information processing method and an electronic device, comprising: obtaining created content in response to a content creation operation; generating a pending-publishing tag record based on the created content in response to a publishing operation, if the current state is under publishing restrictions; wherein the pending-publishing tag record includes the created content and the creation time of the created content; and publishing the pending-publishing tag record when the conditions for lifting the publishing restrictions are met. In this way, when the publishing function is restricted, the user's created content and its creation time can be preserved, which helps to reduce data loss and interruption of the user operation chain caused by directly disabling the function; and delayed publishing based on the creation time improves the integrity of data processing.

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 web applications that support user-generated content, the server typically issues control instructions to directly disable the entry point for content creation and publishing functions on the client during the control period, and displays a message on the graphical user interface indicating that the functions are temporarily unavailable.

[0003] However, the above solution directly cuts off the function entry point at the user interface layer, and users cannot edit or save content in advance during the control period. This not only interrupts the player's immersion, but also misses the best opportunity for emotional resonance and community interaction. 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: in response to a content creation operation, obtaining created content; in response to a publishing operation, if currently under publishing restriction, generating a pending-publishing tag record based on the created content; wherein the pending-publishing tag record includes the created content and the creation time of the created content; and publishing the pending-publishing tag record when the conditions for lifting the publishing restriction are met.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, comprising: an editing module for obtaining created content in response to a content creation operation; a generation module for generating a pending-publishing tag record based on the created content in response to a publishing operation, if the current state is under publishing restrictions; wherein the pending-publishing tag record includes the created content and the creation time of the created content; and a publishing module for publishing the pending-publishing tag record when the conditions for lifting the publishing restrictions are met.

[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 executes the computer program instructions to implement any of the above 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 above information processing methods.

[0009] This disclosure provides an information processing method, comprising: obtaining created content in response to a content creation operation; generating a pending-publishing tag record based on the created content in response to a publishing operation, if the current state is under publishing restrictions; wherein the pending-publishing tag record includes the created content and the creation time of the created content; and publishing the pending-publishing tag record when the conditions for lifting the publishing restrictions are met. In this way, when the publishing function is restricted, the user's created content and its creation time can be preserved, which helps to reduce data loss and interruption of the user operation chain caused by directly disabling the function; and delayed publishing based on the creation time improves the integrity of data processing. Attached Figure Description

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

[0011] Figure 1 This diagram illustrates a flowchart of an information processing method provided in one exemplary embodiment of the present disclosure. 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: In response to the content creation operation, obtain the created content; Step S120: In response to the publishing operation, if the current state is under publishing restrictions, generate a pending-publishing tag record based on the created content; wherein, the pending-publishing tag record includes the created content and the creation time of the created content; Step S130: When the conditions for lifting the release restriction are met, the record to be released is released.

[0021] According to one embodiment of this disclosure, when the publishing function is restricted, the user's created content and its creation time can be retained, which helps to reduce data loss and interruption of user operation chain caused by directly disabling the function; delayed publishing based on creation time improves the integrity of data processing and helps to alleviate the concurrent processing pressure on the server after the control ends, thereby improving the efficiency of server resource utilization.

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

[0023] In step S110, in response to the content creation operation, the created content is obtained. In this way, by preserving the user's entry point for creation and the ability to temporarily store content during the restriction period, not only is the narrative immersion maintained, but also the original material is reserved for subsequent flexible retrospective release.

[0024] In one implementation, after completing a key storyline quest, a player experiences an emotional resonance and then accesses the text and image editing panel by clicking the floating community sharing control on the game's main interface. At this point, the client (such as the first client) detects that it is currently under posting restrictions, so it captures the player's input of storyline reflections and screenshots as creative content, and generates a posting marker record containing the original timestamp (i.e., creation time), instead of directly submitting it to the server. Optionally, the above content creation operation is used to receive user triggers on the user-generated content control to invoke the editing interface and generate the created content.

[0025] Optionally, the aforementioned content creation operations can be any form of user-generated content creation behavior executed by players during the game process by triggering preset interactive entry points. For example, in the post-battle results screen of a multiplayer online tactical competitive game, players can trigger a video editing operation by clicking the "Share Highlights" button; during the story dialogue in a role-playing game, players can trigger annotated text and image creation operations by long-pressing the screenshot control; in the virtual space of the social square, players can trigger a voice message operation by clicking the microphone icon; in open-world games, players can input messages and / or images by calling up road sign props (road signs can be placed anywhere in the game scene, thereby enabling information exchange between players). It should be noted that the aforementioned interactive entry points are not disabled under the publishing restriction state, but remain in a triggerable state to capture the user's immediate creative intent, thereby providing the original behavioral starting point and data source for the subsequent delayed publishing mechanism.

[0026] Optionally, the aforementioned creative content includes edited media data and associated contextual information to recreate the creation scene interface upon publication. Optionally, the creative content may include not only media materials directly input or selected by the player through the editing interface, but also game contextual information strongly associated with the creation moment. Media materials may include text strings typed by the player in the text editor, vector graphics drawn in the drawing panel, screenshots captured in photo mode, highlights edited in the video recording function, and audio data recorded in the voice-over interface. Game contextual information may include the scene identifier code triggered by the creation action, character coordinates, viewpoint parameters, status snapshots of surrounding virtual characters, current task progress indicators, and in-game time and weather parameters. The additional purpose of this contextual information is that when a retrospective release is conducted after the control period ends, the system can accurately recreate the scene interface at the time of content generation based on the aforementioned associated information, ensuring that delayed releases still possess a sense of immediacy and narrative integrity comparable to real-time releases.

[0027] In step S120, in response to the publishing operation, if the current state is under publishing restrictions, a pending-publishing tag record is generated based on the created content; wherein, the pending-publishing tag record includes the created content and the creation time of the created content. In this way, by converting real-time publishing requests into local pending-publishing tag records, not only is the interruption of the creation flow caused by feature disabling avoided, ensuring the user's narrative immersion during special periods, but the original creation time can also be used as a basis for backtracking, ensuring the authenticity and integrity of the timeline of the subsequent content ecosystem.

[0028] For example, in one implementation, after completing a text review of a game storyline, the player clicks the "Publish" control in the lower right corner of the interface. The client detects that the server has issued a control order, and the system is in a publishing restriction state. Therefore, instead of performing a regular network submission, it generates a pending-publishing marker record in the local database. This record at least encapsulates the player's input review text as the creation content, and the original creation time recorded by the client when the creation action is detected. This record is persistently stored in the local pending-publishing list, awaiting confirmation and republication by the player after the control period ends. Optionally, the pending-publishing marker record is used to carry the creation content and creation time during the publishing restriction state, and serves as a data entity for retrospective publishing after the control period ends.

[0029] Optionally, the pending-to-be-published marker record, as a data entity stored locally and persistently, can have its data structure flexibly designed according to actual business needs. In addition to containing the user-edited content and the creation time representing the moment the content was generated, it can also include basic information such as a unique identifier and user identifier, facilitating subsequent indexing, deduplication, and cross-device synchronization management in the pending-to-be-published list. To avoid data loss due to abnormal client exits or process interruptions, this pending-to-be-published marker record can be written to the client's local database or lightweight storage file immediately upon generation, ensuring reliable data preservation. In practical applications, this record can also be further associated with game context information, such as the current level identifier and interface state snapshot, so that the scene atmosphere at the time of creation can be fully restored during subsequent publishing, enhancing the user's immersive experience and willingness to republish during delayed releases.

[0030] Optionally, as a possible implementation, the storage medium for the tags to be published is not limited to the client's local database. While ensuring data privacy and transmission security, it can also be synchronized in real-time to a dedicated cache allocated to the user on the server via an encrypted network channel. This way, when a user switches to another terminal device and logs into the same account, the same tags to be published can be retrieved from the server cache, achieving cross-device content continuity and unified management. It should be noted that the aforementioned cloud synchronization mechanism can be executed in parallel with the local persistence strategy, or it can be selectively enabled based on network conditions, content sensitivity, or user privacy settings. One objective of this embodiment is to reduce the risk of single-point data loss through multi-device collaborative storage, while also providing users with a seamless creative continuity experience across multiple device scenarios.

[0031] Optionally, further, after the record to be published is generated, the client's graphical user interface can provide feedback to the user on the current record saving status through various visual means. For example, a semi-transparent prompt layer can appear in the upper right corner of the interface, displaying the words "Content has been safely saved to the list of items to be published"; or, the visual style of the publish button can switch from a highlighted state to a grayed-out locked state, with a clock icon added to the edge of the button to imply that the content has entered the delayed publication queue. At different stages of operation, the display parameters of the above prompt elements can be dynamically switched according to the number of records. For example, when there is only a single record in the list of items to be published, the prompt layer can automatically collapse into a clickable badge; while when the number of records exceeds a specified threshold, it expands into a detailed information panel, allowing users to quickly view the title, type, and corresponding creation time of all content to be published.

[0032] Optionally, the creation time is used as a system timestamp to represent the moment when a user triggers the creation behavior or completes content editing, and is used as a time reference for subsequent content sorting and retrospective display.

[0033] Optionally, the creation time does not refer to the actual time the client submits content to the server for reception, but specifically to the original timestamp when the user completes content creation under publishing restrictions. This timestamp can be obtained in various ways, such as being recorded by the client when it detects the user's first entry into the content editing interface, or being generated by the local system calling a time interface the moment the user completes all editing and triggers the publishing operation. Considering that players may repeatedly interrupt and resume creation during multiple rounds of gameplay, as a possible implementation, the aforementioned creation time can be set to the system time at the moment the content is finalized, or it can be set to the moment the user first initiates the content creation process; the latter is more relevant in scenarios where the chronological order of events needs to be emphasized. This embodiment decouples the original creation time from the actual publishing time, enabling the community dynamic stream to be sorted according to the actual time of content creation in batch re-publishing scenarios, effectively avoiding the timeline chaos and decreased reading experience caused by a large amount of delayed content piling up at the moment the restrictions are lifted.

[0034] Optionally, the release restriction status is used to characterize the system state where the server temporarily prohibits the real-time uploading of content due to control requirements, and the client switches the release process to local tag storage accordingly. Optionally, the determination criteria for the release restriction status can be diversified, including not only the instantaneous state determined in response to the control instructions actively issued by the server, but also the state transition triggered by the client itself when the preset release restriction time is reached. For example, during the mourning period of a major public event or a special plot phase in the game, the server can broadcast control instructions to clients in a specific region or across the entire server; in another way, the client can automatically enter the release restriction status at a specified start time according to the locally maintained control time schedule, and automatically lift it at a preset end time. Considering that the server has differentiated requirements for different regions or different user groups, the scope of the above-mentioned release restriction status can be precise to a single client, a specified server partition, or a specific user group. One purpose of this embodiment is to ensure that the operator can flexibly respond to sudden needs by introducing a multi-source triggered state determination mechanism, and to avoid the problem of state synchronization lag caused by network latency or instantaneous server overload.

[0035] Optionally, during the publication restriction period, the client's graphical user interface can maintain the interactivity of the content creation entry and publication controls, rather than simply graying them out or hiding them, thereby guiding users to continue creating and forming a pending publication record. It should be noted that, to reduce user confusion when unaware of the restriction, the visual appearance of the publication controls can be adaptively adjusted when the system is in this restricted state. For example, a semi-transparent overlay can be superimposed on its surface, or an hourglass icon and countdown timer can be dynamically displayed next to the controls. This visual feedback clearly informs the user that they are currently in delayed publication mode without abruptly interrupting their creative intent. Furthermore, if a user triggers multiple publication operations consecutively during the publication restriction period, the client can automatically merge multiple creations to generate corresponding pending publication records and arrange them in the local cache according to their creation time, thus laying the data foundation for subsequent batch retrospective publication.

[0036] Optionally, the publish operation is used to trigger a request to transmit completed creative content externally, and to activate a response process that generates a locally generated pending-publishing tag record under publish restriction status.

[0037] Optionally, a publish operation can be a user-triggered action on a specific control in a graphical user interface, or an equivalent publish request generated via voice commands, gesture recognition, or physical button mapping.

[0038] In an optional implementation, the method further includes storing the to-be-published tag locally on the first client. This effectively prevents content loss due to network interception or server rejection during the control period by storing the created content and its timestamp (i.e., creation time) locally on the user's current terminal device, and provides offline data support for subsequent batch retrospective publishing. In practical applications, when the server enters control mode due to data pressure, a specific anniversary, or a public event, the player opens the game client (i.e., the first client) on their current smartphone and edits a comment text at a plot turning point. After the player confirms the publication, the client detects that it is currently under publishing restrictions and therefore does not upload the comment data packet to the game server. Instead, it immediately calls the local database interface to write the to-be-published tag, containing the comment text, the original timestamp of creation time, and the current level identifier, into the embedded storage area of ​​the terminal device. In this way, even if the player subsequently closes the game application or switches to another program, the comment draft will still be safely stored locally, waiting for the player to manually trigger publication or automatically submit in batches after the control period ends.

[0039] Optionally, the first client locally stores the pending-to-be-published tag records to preserve the created content data during the control period. Optionally, the aforementioned local storage on the first client can be specifically represented as an embedded database built into the terminal device or a structured storage area based on a file system. This storage area is directly associated with the main process of the game client and is used to handle created content that would otherwise be submitted to the server during the period when the publishing restriction is in effect. In one specific implementation, after receiving the control instruction and detecting that the user has triggered a publishing operation, the client serializes the pending-to-be-published tag records according to a preset data structure (including a unique identifier, user identifier, original timestamp, created content data, and associated game context information), and then writes it to a designated business table in the local storage. Considering that the control period may last for several hours or even longer, and that the user may switch applications or restart the device multiple times during this period, this local storage area can provide a power-loss protection mechanism to ensure that the written tag records remain intact outside the application's lifecycle. In this way, the local storage on the first client not only serves as a temporary buffer, but also becomes a key data bridge connecting the moment of creation and the moment of publication. This allows the user's immediate expression of intent to be solidified locally, providing the original data foundation for subsequent retrieval, viewing, editing, and publication based on the original timestamp after the control is lifted.

[0040] In an optional implementation, the method further includes: synchronizing the pending-to-be-published tag record to the cache corresponding to the target account on the server; in response to the target account logging in on the second client, reading the pending-to-be-published tag record from the cache corresponding to the target account on the server; and displaying the pending-to-be-published tag record on the interface of the second client. In this way, by synchronizing the local pending-to-be-published record to the server cache and restoring its display on the second client, the loss of created content due to players changing terminal devices is effectively avoided, significantly improving the continuity of user creation and data reliability in cross-device scenarios.

[0041] In one implementation, after a player completes a segment of the game's storyline on a first client (e.g., a smartphone), they trigger the screenshot editing function and add a short comment. At this point, the system is in a posting-restricted state, generating a corresponding pending-posting tag record. This record is synchronized to the cache corresponding to the player's target account on the server. Subsequently, the player logs out of the first client and logs in to the same target account on a second client (e.g., a tablet). The second client reads the aforementioned pending-posting tag record from the server cache and displays it in a list format in its graphical user interface, allowing the player to directly view or continue editing the previously saved UGC (User-Generated Content) draft on the new device.

[0042] Optionally, the cache corresponding to the target account is designed to temporarily store the tag records to be published, so that they can be quickly read and restored for display when logging in across devices.

[0043] Optionally, the cache area corresponding to the target account can be a temporary data residence area deployed on the game server side and uniquely bound to the player account system. Besides hosting the unpublished tag records, it can also store the context index information associated with those records, facilitating rapid reconstruction of the creation scene during cross-platform reading. Considering that players may encounter device failure or insufficient storage space after storing a large number of unpublished tag records locally on the first client, as a possible implementation, the aforementioned cache area can be configured to isolate and save data according to the account dimension after receiving a synchronization request from the first client, thereby effectively avoiding data interference between different players. It should be noted that the above description of the cache area deployment location is only one example. In actual implementation, the cache area can be deployed in a centralized relational database or a distributed object storage system. This disclosure does not intend to limit the physical form of the cache area.

[0044] Optionally, the second client is intended to serve as a cross-platform supplementary terminal to the first client, used to restore the display of pending tag records when a player logs into the target account on a different device. Optionally, the second client can be a heterogeneous hardware device from the first client. For example, when the first client is a smartphone, the second client can be a tablet or personal computer, as long as the device can run the corresponding game client program and support login to the target account. Considering that players may use different terminal devices to play the game in different scenarios, as a possible implementation, after receiving the player's login credentials, the second client can initiate a data synchronization request to the server to read all pending tag records temporarily stored in the cache corresponding to the target account and display them in a list form in the graphical user interface of the second client. It should be noted that the above description of the type of second client is only one example. In actual implementation, the second client can also be another smartphone of the same type, as long as its login target account is consistent with that of the first client. This disclosure is not intended to limit the degree of hardware difference between the second client and the first client.

[0045] Optionally, the second client can display the unpublished tag records in various ways after reading them from the cache. For example, the graphical user interface of the second client can generate a floating window or sidebar panel, which arranges the thumbnail information and content summary of each unpublished tag record in reverse chronological order of creation time, so that players can quickly browse and locate them. On the other hand, the second client can also be configured to overlay a numerical badge or highlight a prompt on a designated function entry in the main interface when unpublished tag records are detected, guiding players to a dedicated unpublished list page for viewing. It should be understood that, regardless of the display format, the data displayed by the second client comes from the cache corresponding to the target account on the server, rather than the data pre-stored locally on the second client, thereby ensuring that players can have a consistent browsing experience of unpublished content when logging in on any qualified terminal device.

[0046] In an optional implementation, the method further includes displaying the created content in a graphical user interface based on a publication time parameter, where the publication time parameter is the creation time. This way, by using the creation time as the publication time parameter, delayed publication content can be displayed in the graphical user interface in order of its actual creation time, accurately reproducing the logical sequence of events and avoiding timeline chaos caused by batch re-publishing. In one example, when a player triggers a publication operation on a record to be published, the client submits the original timestamp of that record as the publication time parameter along with the created content to the server; when the server generates the community display card for this content, it renders the publication time parameter as the creation time and displays it in the information bar of the graphical user interface. Furthermore, the community dynamic stream reorders all content based on this publication time parameter, so that the delayed publication content is inserted into a historical position matching its actual creation time, rather than being placed at the head of the queue of the most recently received content.

[0047] Optionally, in the graphical user interface, the aforementioned publication time parameter can be displayed as an explicit text label directly in the bottom information bar or near the title of the created content, or it can be a hidden parameter for background sorting and not directly exposed to the user. To avoid confusion among viewers regarding the authenticity of delayed publication times, this publication time parameter can be accompanied by specific auxiliary explanatory elements, such as adding the phrase "Created on" next to the time text, or using a different color scheme than real-time publications. It should be understood that when a player chooses to publish multiple marked records in batches, the system can automatically sort them in ascending or descending order based on the publication time parameter; if the player manually adjusts the display order, the graphical user interface can still retain the original publication time parameter as archive information and present the actual sorting sequence number separately.

[0048] Optionally, the aforementioned graphical user interface is designed to provide players with a visual platform for showcasing their created content, which may include, but is not limited to, community feeds or personal content homepages.

[0049] Optionally, the aforementioned graphical user interface can be a touch-screen interface on a smartphone or tablet, or a windowed desktop interface on a personal computer. It at least includes a content display area for loading created content and a time display area for presenting release time parameters. Considering that players may need to review a large number of historical creation records in delayed release scenarios, the graphical user interface can set a time filter control on one side of the content display area. Players can quickly locate all created content within a specific date range by triggering this control. Furthermore, when the created content is in a delayed release status, the graphical user interface can add a specific border style or badge pattern to the content display area, allowing viewers to quickly identify its delayed release attribute in the information flow. It should be noted that the layout configuration, visual style, and human-computer interaction method of the aforementioned graphical user interface can be adaptively adjusted according to different game types or application scenarios, and this disclosure does not limit this.

[0050] In an optional implementation, the method further includes: displaying a list of pending publications in a graphical user interface in response to a markup record viewing operation; wherein the list of pending publications includes at least one pending markup record, and the pending markup records are arranged and displayed in chronological order of creation time. In this way, through the chronological presentation of the pending publication list, users can intuitively trace the entire creative process during the control period, facilitating quick location and batch management of delayed markup content, effectively improving the operational efficiency and user experience continuity of content publishing.

[0051] In one example, after completing a level, a player clicks the "Pending Content" option in the avatar drop-down menu, and a half-screen list page pops up from the bottom of the screen in the graphical user interface. The page displays three marked records generated during the control period, arranged vertically as cards. The original creation timestamp is displayed in the upper left corner of each card, and the records are stacked from bottom to top in chronological order of creation. Players can click on any card to enter the publication confirmation process.

[0052] Optionally, the mark-to-view operation is used to receive a view command triggered by the user to display the list of drafts to be published in the graphical user interface. Optionally, the above mark-to-view operation aims to activate and present the interactive entry point of the list of drafts to be published, and its specific triggering form can be flexibly configured in various interface layers. For example, this view operation can be a single touch operation by the player on a specified function icon in the character information panel, an operation by clicking a specific floating ball in the sidebar of the input area of ​​the instant messaging channel, or an operation by clicking the corresponding pop-up link in a system push message. It should be noted that the above mark-to-view operation can be triggered both during the existence of the publishing restriction state to allow players to check the number of drafts temporarily stored locally in real time, and after the publishing restriction is lifted to uniformly archive and perform batch publishing. Therefore, the response logic of this operation can remain consistent or differ at different times. For example, previews during the restriction period can only provide read-only permissions, while viewing after the restriction is lifted can integrate editing and deletion options.

[0053] Optionally, the pending-to-publish list is used to centrally collect and display at least one pending-to-publish mark record in chronological order, providing a unified entry point for content backtracking. Optionally, the aforementioned pending-to-publish list is used to centrally host and visually present all pending-to-publish mark records generated by the target account during the period of publishing restrictions, with its data organization strictly following the chronological order reflected by the original creation timestamps. For example, this pending-to-publish list can be arranged in a vertical card flow in the central display area of ​​the graphical user interface. Each card entry displays at least a thumbnail preview of the created content, an original creation timestamp accurate to the minute, and the current content status label. The aforementioned preview of the created content can be adaptively adjusted according to the content type; for example, a summary of the first thirty characters can be displayed for text comments, while a compressed cover image can be displayed for screenshots or videos. Furthermore, when the same mark record has multiple versions or has been edited and updated, the latest modification time can be overlaid in the list items, but the overall sorting basis remains fixed at the original creation time, thus ensuring that players have a clear and consistent correspondence in their perception of the content generation timeline.

[0054] Optionally, to avoid information overload caused by displaying a large number of marked records, the presentation of the list to be published can adaptively switch according to the number of marked records, content type, or time span, balancing browsing efficiency and visual clarity. As one implementation, when the number of marked records to be published exceeds a preset threshold, the list can automatically switch to a grouped collapsible mode. The system divides the records into several expandable / collapseable blocks according to natural days or periodic intervals. The title row of each block displays the start and end time range of that period, while the blocks themselves maintain a linear arrangement according to their creation time. Alternatively, the list to be published can be rendered as a horizontally extended timeline view, with earlier created records on the left and later created records on the right, and each record node connected to its corresponding time scale by vertical leaders. It should be noted that regardless of the specific arrangement, the relative order of the marked records to be published based on their original creation timestamps should remain consistent and stable, ensuring that the sequential logic of retrospective publishing matches the user's expectations.

[0055] In an optional implementation, the method further includes: determining the current release restriction state in response to receiving a control command from the server. This way, by having the server proactively issue control commands to uniformly determine the release restriction state, not only can the client quickly enter the delayed release mode, but it can also avoid inconsistencies in function switching caused by local misjudgments, thus improving the accuracy and timeliness of control.

[0056] In one implementation, after determining that a special period control window has been entered, the server issues a control instruction to all online clients. This control instruction includes a control period identifier and a restriction range parameter. Upon successfully receiving the instruction, the client extracts the control period identifier to confirm that it is currently within the restriction period, and then determines its local operating status to be in a restricted publishing state. Optionally, the control instruction can trigger the client to enter the restricted publishing state; it may include a control period and range, allowing the client to determine the restriction level.

[0057] Optionally, the control command is structured data sent by the server to the target client when it detects that a specific period's demand has been met. In addition to the command type used to identify that the command is triggered by a publishing restriction, the control command may also include fields such as the control start and end timestamps, the set of restricted user-generated content function identifiers, and the restriction level. Upon receiving the command, the client parses the command type field to confirm that it needs to enter a publishing restriction state, and determines which user-generated content functions need to be switched to timestamp-marked mode based on the set of restricted function identifiers. This design allows the server to flexibly configure the restriction scope according to actual control needs. For example, it can restrict only user-generated content functions with text input while retaining the real-time publishing capability of pure image recording functions; or it can restrict only user-generated content functions with custom input while retaining the real-time publishing capability of user-generated content with pre-configured system content. This minimizes the impact on user experience while meeting specific needs. It should be noted that the distribution scope of the control command can be a full broadcast or a targeted push to a specific region or user group; this disclosure does not limit this.

[0058] In an optional implementation, the method further includes: in response to an edit trigger operation on the tag record to be published, displaying the creation content corresponding to the tag record to be published and entering an editable state; and in response to an edit confirmation operation, updating the creation content in the tag record to be published. This not only allows users to make secondary revisions to draft content during delayed publication, but also improves the completeness and accuracy of the final published content while preserving the original creation time, effectively avoiding a decline in content quality due to limitations of on-the-spot creation.

[0059] In one implementation, a user writes a battle recap text using in-game comment controls during a special period, and the system generates a corresponding pending-publication marker record based on this. When the user subsequently accesses the view interface of this record, they click the edit icon at the edge of the interface to trigger an editing operation. Upon response, the client loads the original text into the current interface and activates the editable state of the input box. After adjusting some descriptions and verifying that everything is correct, the user clicks the confirmation control to send an edit confirmation operation. The client then replaces the original content in the marker record with the text currently in the input box, thus allowing the user to refine their expression before official publication.

[0060] Optionally, the edit trigger action aims to activate the modification permission of the record to be published, in response to the user's intention to edit the record. Optionally, the edit trigger action can take the form of a long press gesture, a double-click gesture, selecting an edit item in the right-click context menu, or clicking a dedicated edit icon. This action can directly affect the record to be published displayed in the graphical user interface, or it can affect the function entry points associated with that record.

[0061] Optionally, the editable state allows users to modify the created content, enabling them to adjust drafts stored in the markup record. Optionally, the editable state can manifest as a blinking cursor and keyboard activation in the text input area, reactivation of layers in the image editing interface, draggable adjustment of the audio editing timeline, or real-time adjustment of multimedia element parameters. When entering the editable state, in addition to loading the original created content from the local database or server cache, the client can also synchronously restore some interface auxiliary states from when the content was generated, such as the cursor position during the last edit, selected toolbar options, or zoom level. In one specific implementation, if the original created content is text-based comment information, after entering the editable state, the existing text can be loaded into the input control and supports regular add, delete, and modify operations; if the original created content is a combination of screenshots and annotations, the editable state can allow for the repositioning and scaling of the annotation layer, or further editing of the text content. It should be understood that the interface presentation of the editable state can be adapted to the type of created content, and this embodiment does not limit this.

[0062] Optionally, the edit confirmation operation is used to receive confirmation from the user upon completion of content modification, triggering the system to write the modified content into the marker record. Optionally, the edit confirmation operation can be achieved by clicking the confirmation button on the interface, pressing a preset shortcut key combination, performing a specific gesture, or automatically saving and confirming after detecting that the user has left the editing interface and has no further input.

[0063] Optionally, the update is used to write the latest edited and confirmed content back to the pending-publication tag record, and may include the last modified time of the record to improve data dimensions. Optionally, after receiving the edit confirmation operation, the client replaces the original edited content in the pending-publication tag record with the latest content adjusted by the user in the local database to complete the update. Considering that users may use different terminal devices to access the service during the control period, after the above local update is completed, the client can also synchronize the updated pending-publication tag record to the user-specific cache on the server side to ensure that the same account can obtain the latest tag record content when logging into other clients. As a possible implementation, the above update process retains the original timestamp in the tag record as the creation time while replacing the edited content, and adds an additional last modified time field to completely record the full lifecycle information of the content from generation to adjustment. If the edited content is a text string, the update operation can be manifested as a complete replacement of the original string; if the edited content is an image screenshot with annotations, the update operation can be manifested as replacing the image file itself or only updating the annotation layer data superimposed on it. It should be noted that the above description of the update method is only one example, and this disclosure is not intended to limit the underlying implementation of the update operation.

[0064] Optionally, considering the critical importance of the original timestamp in ensuring the authenticity of the community's dynamic timeline, the above update mechanism strictly maintains the original timestamp when performing content replacement. This ensures that even if the created content is subsequently modified and improved, it will still be sorted and indexed according to its original creation time when it is subsequently published and displayed. The last modification time is only recorded as auxiliary information in the extended field. To avoid data redundancy or version management chaos caused by frequent modifications, the system can set an upper limit on the number of historical versions of the unpublished tag record. When the number of versions exceeds the preset threshold, it will automatically merge earlier versions or retain only the most recent modification snapshots.

[0065] In step S130, when the conditions for lifting the publishing restrictions are met, the record to be published is published. Thus, when environmental constraints are lifted, the system can automatically publish the cached record to be published, or the user can actively publish the cached record to be published.

[0066] Specifically, when the conditions for lifting the publishing restrictions are met, the record to be published is published, including: When the conditions for lifting the publishing restrictions are met, the record to be published is set to a publishable state. While the record is in a publishable state, it is published in response to the publishing trigger condition. Thus, when the conditions for lifting the publishing restrictions are met, the system automatically restores previously cached creation entries (i.e., records to be published) to a submit-allowed state, allowing users to promptly notice the end of the restrictions and continue the publishing process, preventing content accumulated during the control period from being missed due to outdated status.

[0067] In one example, after the release restriction period begins, game levels edited by players in the graphical user interface are generated as pending release markers and cached in the local database. When the server detects the end of the restriction period or the arrival of a pre-configured restriction duration threshold, the conditions for lifting the release restriction are considered met. At this point, the client switches the status field of the aforementioned marker record in the local database from a value indicating restricted status to a value indicating that release is permitted, thus setting it to a publishable state. This allows users to see entries with lifted restrictions and permitted to continue submitting in the pending content list after the restriction period ends.

[0068] Optionally, the release restriction lifting conditions are used to determine whether the restricted environment has returned to normal, and can be determined based on the server management end command or local time threshold.

[0069] Optionally, the aforementioned conditions for lifting publishing restrictions can include multiple complementary judgment dimensions. These can be either a control end command actively pushed by the server to the target client after the control period ends, or a state switching signal automatically triggered by a timer maintained locally by the client after reaching a pre-configured time threshold. Considering the fluctuations in the network environment and the potential peak pressure that the server may face when issuing concentrated commands, as a possible implementation, the client can also obtain real-time environmental status indicators by querying the content review open interface during heartbeat interactions with the server to help confirm whether the condition is met. By providing diversified sources of lifting conditions, on the one hand, in the event of server command delays or packet loss, the pre-configured time threshold can be used as a fallback to ensure that users can quickly regain their permissions to operate on and submit previously cached content items after the control window ends; on the other hand, it can adapt to the differences in publishing restriction policies across different platforms, enabling clients to stably complete the automatic transformation of content item status when facing regional or time-based control rules, without requiring users to manually refresh the interface or repeatedly initiate status requests. It should be noted that the above specific description of the conditions for lifting publishing restrictions is only one example, and this disclosure is not intended to limit the source of the judgment for such conditions.

[0070] Optionally, the publishable status indicates that a content item has been released from publishing restrictions, and its form may include a Boolean flag or an enumerated value. Optionally, the publishable status can be accompanied by a binary or multi-dimensional visibility identifier for the aforementioned content item, allowing the client to quickly filter currently available content items based on this identifier, without having to re-examine the creation timestamps or other additional information of all records and perform repetitive real-time checks every time a user enters the pending list. For example, this status can be mapped to a Boolean field in the local database; when the field value is true, it indicates that the record is allowed to respond to the user's publishing trigger action, while during monitoring, the field value is initialized to false.

[0071] In an optional implementation, the method further includes: displaying a publishable notification in the graphical user interface when the conditions for lifting the publishing restrictions are met; wherein the publishable notification indicates the existence of a record marked as ready to be published. This proactive notification, informing users of the existence of content to be published after the restrictions are lifted, effectively prevents players from missing their creations made during the restriction period, thereby improving the conversion rate of delayed publications and further enhancing users' positive perception of the flexible processing mechanism.

[0072] In one implementation, after the server ends its control period and sends a release command to the client, a red badge with the number "3" immediately appears in the upper right corner of the previously static content publishing function entry on the player's mobile terminal's main game interface. Simultaneously, a banner notification slowly slides down from the top of the screen, displaying "You have 3 posts to publish. Click to quickly review." After the player clicks the banner, the interface smoothly transitions to the posting list page, where three marked records are arranged in chronological order of creation time. The player can check each post and execute the publishing operation. The badge and banner together constitute a publishing notification, designed to ensure that players are informed of the reopening of the delayed publishing channel immediately upon entering the game through multi-layered visual feedback.

[0073] In an optional implementation, the conditions for lifting the publishing restriction are met, including: receiving a control termination command from the server; or reaching a time threshold for the publishing restriction. This allows the server to proactively lift the publishing restriction via a control termination command, or the client to automatically lift the publishing restriction via a time threshold. Alternatively, both mechanisms can be used in parallel to avoid the risk of failure under network anomalies caused by a single triggering method.

[0074] As one implementation method, when the server determines that the special period control has ended, it can send a control end command to the client. After the client parses the command, it switches the status of the pending-to-publish mark record to the publishable status. As another implementation method, the time threshold of the publishing restriction can also be preset in the client or server, for example, set to a specific end date. When the system time reaches that time, the client automatically determines that the conditions for lifting the publishing restriction are met.

[0075] Optionally, the control termination instruction is generated and issued by the server. Upon receiving it, the client switches the pending-to-be-published record to a publishable state accordingly. Optionally, the data carrier format of the control termination instruction can be diverse. It can be an independently constructed control signaling message, a specific field within a regular business data packet, or a specific payload format embedded in a push notification. In one implementation, when the server determines that the control period has ended, it sends the instruction to the target client within the control scope via the network. After receiving the data packet, the client extracts the status identifier field to confirm that the control has ended, and then sets the locally stored pending-to-be-published records to a publishable state in batches or individually. This flexible setting of the control termination instruction's carrier format allows for the reuse of existing communication channels to reduce system modification costs and facilitates compatibility in instruction parsing within heterogeneous client environments. It should be noted that the instruction's issuance logic is not limited to unicast. To improve issuance efficiency, the server can also send the instruction to multiple clients simultaneously via multicast or broadcast; this disclosure does not limit this.

[0076] Optionally, the time threshold for release restrictions represents the target time when the system automatically lifts the release restrictions; once the threshold is reached, the conditions for lifting the release restrictions are determined to be met.

[0077] Optionally, the time threshold for publishing restrictions can be configured uniformly on the server side, or the client can obtain it from the server and cache it locally when it receives the control command. In one implementation, when the server initiates publishing restrictions due to special anniversaries or other requirements, it carries an expected end timestamp in the control command sent downwards. After receiving this timestamp, the client stores it as a time threshold in local non-volatile memory. Subsequently, the client's scheduled task or system alarm service continuously compares the current system time with the time threshold in the background. When it detects that the current time has reached or exceeded the threshold, it automatically triggers the state change logic, sets the pending-to-publish record to a publishable state, and displays a publishable prompt to the user in the form of a pop-up window or badge in the graphical user interface. In this way, even if the server fails to send the control end command in time due to instantaneous high concurrency or its own failure at the end time, the client can independently complete the release judgment based on the local time threshold, significantly improving the reliability of the system in weak network or no network environment.

[0078] Optionally, the aforementioned publishing trigger operation can be a confirmation publishing action performed by the player on a single pending-publishing marked record. Specifically, in the pending-publishing list displayed in the graphical user interface, each marked record in the publishable state can be configured with an independent publishing control, such as the "Publish" button located on the right side of the record card. When the player presses this button via touch or mouse, the client encapsulates the record's unique identifier, user-generated content data, and original timestamp into a publishing request message and sends it to the server's content publishing interface. Considering that players may accumulate multiple pieces of content during the control period, a batch selection operation can also be performed on all or part of the records in the pending-publishing list, and then a one-click confirmation can be completed through the unified batch publishing control at the bottom or top of the interface. In this way, through the dual design of single-record confirmation and batch confirmation, both the player's refined needs for filtering and publishing specific content are met, and the convenient demand for efficiently clearing the pending-publishing queue is also taken into account, effectively balancing the relationship between operational flexibility and publishing efficiency.

[0079] Optionally, in addition to the manual publishing mode triggered by players as described above, an automatic publishing mode can also be enabled in the client settings beforehand, making the release process after the control ends more seamless. In this mode, after receiving the control end command from the server, the system can automatically submit publishing requests to the server in order of creation time of each pending publishing record from earliest to latest, without waiting for players to confirm each one. If a record cannot be successfully published during the automatic publishing process due to expired content format or exceeding server capacity limits, the system can pause the subsequent automatic submission process and prompt the player to enter the manual processing interface for intervention in the graphical user interface via a bubble notification, or choose to skip the abnormal record and continue the automatic publishing of the remaining queue. It should be noted that the choice between the above-mentioned automatic and manual publishing triggering logics depends not only on the player's personalized usage habits, but can also be combined with the content sensitivity classification strategy, so that highly sensitive content is forced into the manual confirmation stage, while ordinary content is allowed to be automatically released. In this way, not only is the operational burden on players further reduced after the control ends, but the necessary manual review window is also retained through the classification control mechanism, taking into account both convenience and the needs of special periods.

[0080] Optionally, the above posting is intended to submit the publishable content and its original timestamp to the server to reconstruct the community timeline at the time of creation.

[0081] Optionally, when executing the above-mentioned publishing, the client can encapsulate the locally persistent user-generated content data, associated scene information, and most importantly, the original timestamp, into a single publishing request and send it to the server. Considering the stability of network transmission and the requirements for data integrity, the publishing request can be submitted to the server's content receiving interface through an encrypted transmission channel, carrying a unique identifier, user identity credentials, the content body, media file index, and the original timestamp field in the request body. Upon receiving the request, the server first parses the original timestamp and writes it into the generation time field of the content database. Simultaneously, it establishes an inverted index based on this timestamp for subsequent timeline sorting of the community's dynamic stream. In other words, even if the content is received by the server the day after the control measures end at the actual streaming level, the publishing moment visible to players at the community display level will still be the moment the player actually completed the creation three days prior. This backtracking mechanism using the original timestamp effectively avoids timeline chaos in the community caused by delayed publishing, ensuring that the logical order of events remains consistent with players' emotional memories.

[0082] In an optional implementation, the tag record to be published also includes associated scene information; publishing the tag record includes: based on the associated scene information, restoring the scene interface at the time the content corresponding to the tag record was generated. This preserves the user's context and emotional memory during creation, accurately restoring the original scene state during retrospective publishing, effectively avoiding cognitive breaks caused by spatiotemporal mismatches, and thus significantly enhancing the immersive experience and narrative authenticity of the republishing operation.

[0083] Optionally, the associated scene information is used to describe the game state and interface parameters at the moment of creation, supporting lossless reconstruction of the original scene during the release phase. Optionally, the associated scene information may include, but is not limited to, one or more of scene identifiers, viewpoint parameters, and interface element states. The scene identifier uniquely identifies the virtual space where the player is located when the creation occurs, such as the map number of the current game, the chapter sequence number of a story level, or the room identifier of the social lobby; viewpoint parameters record the camera's position coordinates, orientation angle, and field of view in three-dimensional space to ensure that the player's observation orientation remains consistent with that during creation; and interface element states capture the visibility, arrangement, and interactive attributes of various functional controls in the graphical user interface. Through the combination of these multi-dimensional information, the system can accurately reconstruct the complete human-computer interaction environment at the moment of creation during the delayed release phase, avoiding the loss of original contextual relevance by only presenting isolated content.

[0084] Optionally, in addition to static spatial and interface description parameters, the associated scene information can be dynamically expanded to include other types of contextual data based on the differences in application scenarios. For example, in online battle applications, the associated scene information can also include the lineup configurations of both sides, real-time battle report data, and environmental sound effect identifiers, thereby synchronously restoring the battle atmosphere at the time during replay. In narrative applications, the associated scene information can further include the branch node number of the current dialogue tree, the position coordinates of non-player characters, and their facial expressions, ensuring that players can re-enter the emotional rhythm at the time when reviewing their creations. It should be noted that the above types are only examples, and the granularity and field composition of the associated scene information can be flexibly configured according to the specific game type characteristics and data tracking strategies. This disclosure does not limit this.

[0085] Optionally, the scene interface is reconstructed based on associated scene information to restore the virtual scene and interactive layout at the moment of creation during the publishing phase. Optionally, the restoration process of the scene interface can load the corresponding basic environmental resources based on the scene identifier in the associated scene information, adjust the spatial pose of the virtual camera based on the viewpoint parameters, and restore the display logic of each control in the graphical user interface according to the state of the interface elements. For example, if the created content is a screenshot or video clip generated during an intense battle, after loading the map resources corresponding to the scene identifier, the system moves the camera position to the recorded 3D coordinates and orients it according to the recorded pitch and yaw angles, allowing the player to re-observe the battlefield situation at that time. Furthermore, the system will also restore the text input boxes, emoticon selection bars, and publish buttons in the user editing interface to their visible state and screen coordinates at the time of creation, thereby completely reproducing the creative environment at the visual and interactive levels and providing players with a highly consistent retrospective experience.

[0086] In an optional implementation, based on the associated scene information, the scene interface at the time of creation corresponding to the record to be published is reconstructed. This includes: reconstructing the scene interface at the time of creation based on the scene identifier, viewpoint parameters, and interface element states in the associated scene information, and loading the creation content into the scene interface. In this way, by combining and calling scene identifiers, viewpoint parameters, and interface element states, not only can the scene and interaction context at the time of creation be accurately reproduced, but a consistent visual retrospective experience can also be provided during re-release, thereby improving the narrative continuity and immersion under the delayed release mechanism.

[0087] In one implementation, after the server terminates control and issues a release notification, the user opens the pending release list and selects a scene marker record generated three days prior during a scene setup in the beginner level. The client reads the associated scene information from this record, locates the relevant resources based on the scene identifier, reconstructs the original viewing angle according to the 35-degree pitch angle, 120-degree horizontal rotation angle, and 8-meter viewing distance parameters, and then restores the rotation, movement, and other control settings according to the state of the interface elements. Subsequently, the client loads the turntable, obstacles, etc., that the user had added at the time into the center of the reconstructed scene interface, and executes the release with the original timestamp after user confirmation.

[0088] Optionally, the scene identifier aims to uniquely identify the map, instance, or level resource corresponding to the record to be published, and serves as the basic index for recreating the scene interface. Optionally, the scene identifier can be in the form of a map number, level name, instance identifier, or scene hash value, as long as it can be recognized by the game engine and used to call the corresponding scene resource. Considering that users may need to span multiple game versions during delayed releases, as a possible implementation, the scene identifier can also include a resource version number or patch serial number to avoid restoration failures due to scene resource iteration updates. In actual presentation, the scene identifier can be stored separately as metadata in the record to be published, or it can be embedded in the header field of the associated scene information. It should be noted that the above description of the scene identifier's structure is only an example; in actual implementation, it can be flexibly determined according to the game's map size, level complexity, and data compression requirements.

[0089] Optionally, in addition to directly pointing to static map resources, scene identifiers can also point to dynamically generated replica instance numbers or random event seeds to ensure that the special terrain or variant scenes generated by the algorithm can be reproduced during restoration. To avoid identifier invalidation due to server merging or partition adjustments, as a possible implementation, the client can also save a globally unique server cluster code and logical server sequence number simultaneously during the recording phase; during the backtracking phase, the client first verifies whether the current server region matches the cluster code in the record. If there is a difference, a mapping conversion is performed through the cross-server resource routing table, thereby ensuring the accuracy and stability of scene restoration.

[0090] Optionally, the viewpoint parameters are used to record the virtual camera position and viewing orientation at the moment the creative action is triggered, so as to restore the user's original viewing perspective during the retrospective phase. Optionally, the viewpoint parameters can be the camera's three-dimensional coordinates, pitch angle, yaw angle, and field of view in the world coordinate system, or the relative distance and orbital angle around the character's target point. In one implementation, when capturing the creative action, the client extracts the above viewpoint parameters in real time from the game engine's camera module and writes them into the pending-publishing marker record; during the retrospective restoration phase, the client injects the above parameters into the scene's rendering pipeline, so that the virtual camera instantly returns to the viewing position at the time of creation, thereby ensuring that the scene composition seen by the user when viewing or editing delayed-published content is completely consistent with that at the time. It should be noted that, in addition to including basic spatial orientation information, the viewpoint parameters can also include extended information such as depth of field, focal length, or post-processing effects on / off status, which this disclosure does not limit.

[0091] Optionally, the interface element state is used to characterize the visibility, interaction, or layout of various controls in the graphical user interface when the creative action is triggered, to assist in recreating the operating environment. Optionally, the interface element state may include the expanded or collapsed indicator of the main city function bar, the transparency and position coordinates of the chat window, the floating state of the task tracking panel, and the layout information of the custom quick skill panel. Since different players may adjust the interface layout according to their own habits when taking screenshots or recording content, or even temporarily hide some controls to obtain a clean screen, as a possible implementation, the client performs snapshot-style storage of the above-mentioned interface element states while recording the creative action; during the retrospective restoration, the position, size, and visibility of each control are restored one by one according to the snapshot information, and after the scene interface is loaded, the creative content is superimposed on the restored interface layer and presented to the user. It should be understood that the interface element state may also include the real-time state of the input method panel, bullet screen switch, or system notification bar, which is not limited in this embodiment.

[0092] An information processing apparatus according to one embodiment of the present disclosure, such as Figure 2 As shown, the device may include: Editing module 201 is used to obtain the created content in response to the content creation operation; The generation module 202 is used to respond to the publishing operation and, if the current state is under publishing restrictions, generate a record to be published based on the created content; wherein, the record to be published includes the created content and the creation time of the created content; The publishing module 203 is used to publish the record to be published when the conditions for lifting the publishing restrictions are met.

[0093] In this way, even when the publishing function is restricted, users' creative content and their creation time can be preserved, which helps to reduce data loss and interruption of user operation chain caused by directly disabling the function; delayed publishing based on creation time improves the integrity of data processing and helps to alleviate the concurrent processing pressure on the server after the control ends, thereby improving the efficiency of server resource utilization.

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

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

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

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

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

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

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

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

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

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

Claims

1. An information processing method characterized by comprising: The method includes: Responding to content creation operations, obtain the created content; In response to a publishing operation, if the current state is under publishing restrictions, a pending-publishing tag record is generated based on the created content; wherein, the pending-publishing tag record includes the created content and the creation time of the created content; When the conditions for lifting the publishing restrictions are met, the record to be published is published.

2. The method of claim 1, wherein, The step of publishing the record to be published when the conditions for lifting the publishing restrictions are met includes: When the conditions for lifting the publishing restrictions are met, the record to be published is set to a publishable state; When the tag record to be published is in the publishable state, the tag record to be published is published in response to the publication trigger condition.

3. The method of claim 1, wherein, The method further includes: The record to be published is stored locally on the first client.

4. The method of claim 3, wherein, The method further includes: Synchronize the record to be published to the cache area corresponding to the target account on the server; In response to the login of the target account on the second client, the pending publication tag record is read from the cache corresponding to the target account in the server; The record to be published is displayed in the interface of the second client.

5. The method according to claim 1, characterized in that, The tag record to be published also includes associated scenario information; The publication of the creation record includes: Based on the associated scene information, the scene interface at the time when the creation content corresponding to the record to be published was generated is restored.

6. The method of claim 1, wherein, The method further includes: The created content is displayed in the graphical user interface based on the publication time parameter, wherein the publication time parameter is the creation time.

7. The method of claim 2, wherein, The method further includes: When the conditions for lifting the publishing restrictions are met, a publishable prompt message is displayed in the graphical user interface; wherein, the publishable prompt message is used to indicate that there is a record marked as to be published that is in a publishable state.

8. The method of claim 5, wherein, The step of restoring the scene interface at the time of content creation corresponding to the record to be published, based on the associated scene information, includes: Based on the scene identifier, perspective parameters, and interface element status in the associated scene information, the scene interface at the time of the creation of the content is restored, and the creation content is loaded into the scene interface.

9. The method of claim 1, wherein, The method further includes: In response to the mark record viewing operation, a list of pending publications is displayed in the graphical user interface; wherein the list of pending publications includes at least one of the pending mark records, and the pending mark records are arranged and displayed in chronological order according to the creation time.

10. The method of claim 1, wherein, The method further includes: Upon receiving a control command from the server, it determines that it is currently under release restrictions.

11. The method of claim 1, wherein, The method further includes: In response to an edit trigger operation on the record to be published, the created content corresponding to the record to be published is displayed and the record enters an editable state; In response to the edit confirmation operation, update the creation content in the pending publication tag record.

12. An electronic device, comprising: 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 11.

Images