An information processing method and device in a game and a storage medium

Abstract

This invention provides a method, device, and storage medium for information processing in games. The method includes: responding to a task viewing operation, displaying a calendar interface corresponding to a first game account through a graphical user interface. The calendar interface displays game task information related to the first game account, including execution time information and content information; responding to a trigger operation on a target game task in the calendar interface, executing game processing logic corresponding to the trigger operation. This invention associates the calendar interface with game processing logic. When a player performs a trigger operation on a target game task in the calendar interface, the corresponding game processing logic is directly executed. This design, which deeply integrates task information display with in-game operations, shortens the path from reading task information to executing the task, improves the convenience and response efficiency of task management, and optimizes the overall gaming experience for players.

Description

Technical Field

[0001] This invention belongs to the field of game interface technology, and in particular relates to information processing methods, devices and storage media in games. Background Technology

[0002] In simulation games, players typically participate in group missions issued by alliance leaders or the system, such as sieges, rallies, and resource wars. Currently, mission information notifications mainly rely on in-game mail, chat channels, and verbal communication between players. This notification method results in mission information being scattered across multiple channels, requiring players to frequently switch interfaces to piece together a complete mission schedule, making it difficult to intuitively grasp the priority and urgency of missions.

[0003] To address this issue, those skilled in the art have integrated task information into a calendar interface to centrally display the time and content of tasks. However, existing game calendar interfaces typically function only as static information lists, allowing users to view tasks but not directly interact with them. This one-way information display method severs the connection between task notifications and specific in-game actions. After receiving a task notification, users still need to manually perform subsequent steps, resulting in a lengthy and inefficient operation path. Summary of the Invention

[0004] In view of this, the present invention provides an information processing method, device and storage medium for games, enabling users to directly trigger task-related operations in the calendar, thereby improving the convenience and efficiency of task management.

[0005] A first aspect of the present invention provides an information processing method for a game, wherein a graphical user interface is provided through a first terminal, the graphical user interface displaying at least a portion of a virtual scene, the method comprising:

[0006] In response to the task viewing operation, the calendar interface corresponding to the first game account is displayed through the graphical user interface. The calendar interface is used to display game task information related to the first game account. The game task information includes execution time information and content information.

[0007] In response to a trigger operation on a target game task in the calendar interface, the game processing logic corresponding to the trigger operation is executed.

[0008] A second aspect of the present invention provides an information processing method for a game, wherein a graphical user interface is provided via a second terminal, the graphical user interface displaying at least a portion of a virtual scene, the method comprising:

[0009] In response to a task release trigger operation, the task editing interface is displayed through the graphical user interface.

[0010] In response to an editing operation on the task editing interface, game task information is determined, which includes time information, content information, and executor information;

[0011] In response to the task release confirmation operation, the game task information is sent to the executor so that it can be displayed in the executor's corresponding calendar interface. (Calendar interface)

[0012] A third aspect of the present invention provides an information processing apparatus for a game, which provides a graphical user interface via a first terminal, the graphical user interface displaying at least a portion of a virtual scene, including:

[0013] The calendar interface display module is used to respond to task viewing operations and display the calendar interface corresponding to the first game account through the graphical user interface. The calendar interface is used to display game task information related to the first game account. The game task information includes execution time information and content information.

[0014] The execution module is used to respond to a trigger operation on a target game task in the calendar interface and execute the game processing logic corresponding to the trigger operation.

[0015] A fourth aspect of the present invention provides an information processing apparatus for a game, which provides a graphical user interface via a second terminal, the graphical user interface displaying at least a portion of a virtual scene, the apparatus comprising:

[0016] The editing interface display module is used to display the task editing interface through the graphical user interface in response to the task release trigger operation;

[0017] The game task information determination module is used to determine game task information in response to the editing operation of the task editing interface. The game task information includes time information, content information, and executor information.

[0018] The task sending module is used to send the game task information to the executor in response to the task release confirmation operation, so as to display the game task information in the calendar interface corresponding to the executor.

[0019] A fifth aspect of the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the information processing method in a game as described in the first aspect above.

[0020] A sixth aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the information processing method in a game as described in the first aspect above.

[0021] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0022] This invention links the calendar interface with game processing logic. When a player performs a trigger action on a target game task in the calendar interface, the corresponding game processing logic is executed directly. For example, a player can directly close the calendar and jump to the virtual scene associated with the task by clicking on the task, without having to manually search for the scene or switch interfaces after learning about the task. This design, which deeply integrates task information display with in-game operations, shortens the path from reading task information to executing the task, improving the convenience and responsiveness of task management. In summary, this invention, by designing the calendar interface as an interactive operation entry point, achieves seamless integration of task notifications and game logic, optimizing the player's overall gaming experience. Attached Figure Description

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

[0024] Figure 1 This is a schematic diagram of an information processing method in a game provided by an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of a calendar interface provided in an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of a calendar interface provided in an embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram illustrating the adjustment of the display area height according to an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of a segmented compression method provided in an embodiment of the present invention;

[0029] Figure 6 This is a schematic diagram comparing the layout of game task information before and after adjustment, provided by an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram of an information processing method in a game provided by an embodiment of the present invention;

[0031] Figure 8 This is a schematic diagram of a task editing interface provided in an embodiment of the present invention;

[0032] Figure 9 This is a schematic diagram illustrating how to update task time in a calendar interface by dragging and dropping, as provided in an embodiment of the present invention.

[0033] Figure 10 This is a schematic diagram of an information processing device for a game provided in an embodiment of the present invention;

[0034] Figure 11 This is a schematic diagram of an information processing device for a game provided in an embodiment of the present invention;

[0035] Figure 12 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0036] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the present invention. However, those skilled in the art will recognize that the present application may be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail that could obscure the description of the present application.

[0037] The technical solution of the present invention will be illustrated below through specific embodiments.

[0038] Reference Figure 1 The diagram illustrates an information processing method in a game according to an embodiment of the present invention. This method can be executed by an information processing device in the game. The display system for game task information in the calendar can be implemented in hardware and / or software. The information processing device in the game can be configured in an electronic device.

[0039] It should be noted that this method provides a graphical user interface (GUI) through a first terminal (such as a smartphone, tablet, or personal computer), which displays at least a portion of the virtual scene. This virtual scene can be a 3D environment, map interface, or battle scene within a game. The first terminal corresponds to the first game account, i.e., the game account currently controlled by the player.

[0040] like Figure 1 As shown, the method may specifically include the following steps:

[0041] S101. In response to the task viewing operation, the calendar interface corresponding to the first game account is displayed through the graphical user interface. The calendar interface is used to display game task information related to the first game account. The game task information includes execution time information and content information.

[0042] Specifically, players can view tasks by clicking specific icons (such as the "Schedule" or "Task" buttons) on the main game interface, or by using preset shortcuts or gestures. When the system detects this task viewing action, a calendar interface will be displayed on the graphical user interface. This calendar interface is used to centrally display game task information related to the primary game account. Each game task includes at least execution time information and content information. The execution time information can be a specific point in time (such as "20:00 Siege") or a time period (such as "14:00-16:00 Gathering"); the content information is a description of the task, such as the task objective, location, and rewards.

[0043] The calendar interface can adopt a common calendar format, such as using a week or several days as the time span and arranging game task information in chronological order. Each game task can be displayed at its corresponding time position, allowing players to intuitively see the task schedule for each time period of the day. This centralized display method overcomes the shortcomings of scattered information in traditional emails and chat channels, allowing players to grasp all pending tasks without frequently switching interfaces.

[0044] In an optional example, such as Figure 2 The diagram shows a calendar interface, which includes a timeline 21 and a taskbar 22.

[0045] In a calendar interface, the timeline is typically a continuous, scaled vertical / horizontal linear coordinate system. It maps an abstract, continuous flow of time (such as 24 hours in a day) to specific, discrete pixel positions on the screen. Each point in time (such as 14:30) or time period (such as 14:30-16:00) can find its corresponding start coordinates (top) and end coordinates (bottom) on the timeline through defined mapping rules.

[0046] In this example, the taskbar is a vertically oriented container area with a fixed width, parallel to the timeline. It serves as a container for game task information, such as... Figure 2 As shown, game task information 23 is arranged in the corresponding task bar 22. For example... Figure 2 As shown, in addition to the current date (August 4th), the task bar 22 corresponding to the dates of the next two days can be arranged side by side, so that players can intuitively see the tasks that need to be prepared for the current date and the next two days.

[0047] The width of the taskbar refers to the area scale parallel to the time axis.

[0048] S102. In response to a trigger operation on a target game task in the calendar interface, execute the game processing logic corresponding to the trigger operation.

[0049] Once the calendar interface is displayed, players can trigger an action on any game task (i.e., the target game task). Triggering actions can be gestures such as clicking, long-pressing, or double-tapping, or selection using the virtual cursor or keyboard. When the system detects the triggering action, it will identify the task and execute the corresponding game processing logic.

[0050] Game processing logic refers to the specific in-game behaviors executed by the system in response to triggered operations; different triggered operations can correspond to different logic. For example:

[0051] In one embodiment, the triggering operation can be a single click, and the corresponding game processing logic is to jump to the mission location: when a player clicks on a siege mission, the system automatically closes the calendar interface and switches the graphical user interface to the virtual scene area (such as battlefield coordinates) associated with the mission, allowing the player to directly participate in the battle.

[0052] In another embodiment, the triggering operation can be a long press, and the corresponding game processing logic is to share a task: when a player long presses a task, the system pops up a sharing option panel, and the player can choose to send the task information to the chat channel or social platform to invite allies to participate.

[0053] In another embodiment, the triggering operation can be a double-click, and the corresponding game processing logic is to view details: when the player double-clicks the task, the system displays a pop-up window containing more detailed information, such as task description, participating members, reward preview, etc.

[0054] It should be noted that the above-mentioned triggering operations (single click, long press, double click) and their corresponding game processing logic are merely illustrative examples. Those skilled in the art can configure different triggering operations and logic combinations for different types of tasks according to actual game design needs, and these all fall within the protection scope of this invention.

[0055] Through these triggering operations, this invention transforms the calendar interface from a static information display panel into a dynamic interactive entry point, allowing players to jump directly from task notifications to relevant game logic, greatly shortening the operation path and improving the gaming experience.

[0056] This invention links the calendar interface with game processing logic. When a player performs a trigger action on a target game task in the calendar interface, the corresponding game processing logic is executed directly. For example, a player can directly close the calendar and jump to the virtual scene associated with the task by clicking on the task, without having to manually search for the scene or switch interfaces after learning about the task. This design, which deeply integrates task information display with in-game operations, shortens the path from reading task information to executing the task, improving the convenience and responsiveness of task management. In summary, this invention, by designing the calendar interface as an interactive operation entry point, achieves seamless integration of task notifications and game logic, optimizing the player's overall gaming experience.

[0057] In an optional embodiment, the information processing method in the game further includes:

[0058] In response to the task type selection operation, the game task information corresponding to the target task type is displayed in the calendar interface;

[0059] The target task type includes at least one of the following: game tasks related to the first game account issued by the second game account, and game tasks related to the first game account issued by the system, wherein the second game account and the first game account are allies.

[0060] Specifically, the calendar interface can be configured with one or more filter controls, such as drop-down menus, tabs, or checkboxes, to allow players to select the type of tasks they wish to view. When a player performs a task type selection action (such as clicking the "Allied Tasks" tab or checking the "System Tasks" checkbox), the system responds by filtering the game task information displayed in the current calendar interface, showing only game task information that matches the selected target task type.

[0061] Optional, such as Figure 2 As shown, the calendar interface also includes a filter control 24. This filter control 24 allows filtering of game task information by type. The types include system-issued game tasks related to the first game account (referred to as system tasks) and game tasks issued by the second game account related to the first game account (referred to as team tasks). The options are "Self" and "Team," where "Self" corresponds to system tasks and "Team" corresponds to team tasks. Figure 2 In the middle, by selecting "All" through the filter control 24, the checkboxes of both the "Myself" and "Squad" labels are checked, indicating that the tasks of "Myself" and "Squad" are displayed at the same time. Among them, the game task information with the "Flag" icon corresponds to the "Squad" tasks, and the game task information without the "Flag" icon corresponds to the "Myself" tasks.

[0062] In an optional embodiment, in response to a trigger operation on a target game task in the calendar interface, game processing logic corresponding to the trigger operation is executed, including:

[0063] In response to the first trigger operation on the target game task in the calendar interface, the calendar interface is closed, and the graphical user interface is controlled to display the virtual scene area corresponding to the target location, where the target location is the location associated with the target game task.

[0064] Specifically, each game mission can be associated with a target location in a virtual scene. This target location can be the mission execution location, such as the castle coordinates in a siege battle, the camp location of a rally point, or a resource point.

[0065] When a player performs the first trigger action on a target game task in the calendar interface (such as clicking on game task information), the system detects the first trigger action and then executes the corresponding game processing logic: First, the currently displayed calendar interface is closed; then, the graphical user interface is controlled to automatically switch to the virtual scene area corresponding to the target location associated with the task, such as moving the center of the game map to that location, or directly loading the scene view of that location, so that the player can immediately execute the task.

[0066] In one example, suppose the calendar interface displays a mission "Attack Blackrock Fortress at 20:00," with the target location being the coordinates of Blackrock Fortress. If the player clicks on this mission information at 19:55, the calendar interface closes, and the game screen instantly switches to the area near Blackrock Fortress. The player can directly observe the battlefield environment, assemble their team, or check the resources required for the mission (such as health potions and stamina) without manually opening the map, finding the coordinates, or reconfirming the mission details.

[0067] It should be noted that the specific form of the first triggering operation (such as a click) and the definition of the task-related location can be flexibly configured according to the actual needs of the game. This embodiment is only an example.

[0068] This embodiment integrates task viewing and scene transitions, greatly shortening the path from task awareness to action execution, and improving player operational efficiency and game immersion.

[0069] In an optional embodiment, in response to a first trigger operation on a target game task in the calendar interface, the calendar interface is closed, and the graphical user interface is controlled to display the virtual scene area corresponding to the target location, including:

[0070] In response to an action to view details of a target game task in the calendar interface, the task details interface is displayed, which includes a go-to control; in response to an action triggered by the go-to control, the calendar interface is closed, and the graphical user interface is controlled to display the virtual scene area corresponding to the target location.

[0071] When a player performs a view operation on a target game task in the calendar interface (e.g., double-clicking the game task information), the system responds by displaying a task details interface. This task details interface provides a more comprehensive view of the target game task and can contain richer information than the calendar interface, such as the complete task description text, the name and coordinates of the task's target location, a preview of the task rewards, a list of allies participating in the task, the task status (such as "Pending Start," "In Progress," "Completed"), or other task-related auxiliary information.

[0072] The task details interface includes a navigation control, such as a button labeled "Go," "Jump," or "Participate." When a player clicks this navigation control, the system responds to the trigger action and executes subsequent game processing logic: first, it closes the currently displayed calendar interface (and the task details interface), and then it controls the graphical user interface to automatically switch to the virtual scene area corresponding to the target location associated with the task. For example, it moves the center of the game map to that location or directly loads the scene view of that location, allowing the player to immediately begin task execution.

[0073] In one example, please refer to: Figure 3 The diagram illustrates a calendar interface. When a player (via touch) selects a target game mission (“The Fight!”), the system responds and displays a mission details interface 31 in the associated area (as shown below). This interface fully displays all information about the target mission, including the scheduled time (“Sunday, August 5th, 09:15”), a detailed event description, location (coordinates), reminders, and a "go to" control 311. When the player clicks the "go to" control 311, the system responds to the trigger operation and executes the corresponding game processing logic: first, it closes the currently displayed calendar interface; then, it automatically switches the graphical user interface to the virtual scene area corresponding to the target location associated with the mission, allowing the player-controlled virtual character or object to immediately enter the virtual area designated by the mission.

[0074] This embodiment, while providing a quick jump function, adds a preview of task details, allowing players to fully understand the task background and requirements before jumping, avoiding misoperation due to insufficient information. At the same time, the "go to" control serves as a clear confirmation entry point, giving players full control and improving the certainty of the interaction and user experience.

[0075] In an optional embodiment, in response to a trigger operation on a target game task in the calendar interface, game processing logic corresponding to the trigger operation is executed, including:

[0076] In response to a second triggered action on the target game task in the calendar interface, share the target game task to the target platform.

[0077] When a player performs a second triggering action on a target game task (such as long-pressing the game task information or clicking the "share" icon on the right side of the game task information), the system responds to the second triggering action and initiates the task sharing process.

[0078] Upon detecting the second triggering operation, the system will invoke the sharing function to share the relevant information of the target game task to the target platform. The target platform may include, but is not limited to:

[0079] In-game chat channels, such as alliance channels, squad channels, and private chat windows; social platforms outside the game; and other in-game messaging systems, such as mail and message boards.

[0080] The shared content can include task execution time information, content information, and optional additional information, such as the task target location, task publisher, and task status. The system can present the shared content in the form of text messages, card messages, or interactive links. After receiving the share, if the recipient is also a game player, they can even directly jump to their calendar interface or task details page by clicking on the shared content.

[0081] For example, please refer to Figure 3 When a player clicks or long-presses the target game mission (“The Fight!”), the system displays a share control 32 in the calendar interface. Furthermore, when the system detects a player clicking the share control 32, a share options panel pops up, including options such as “Send to Alliance Channel” and “Send to Squad Channel.” If the player selects “Send to Alliance Channel,” the system immediately sends the mission information as a card to the alliance chat channel. Other allies can click the card to view the mission details or add it to their calendars.

[0082] This design integrates the calendar interface with social features, allowing players to quickly synchronize task information with allies or external contacts. This facilitates team collaboration and information dissemination, improving communication efficiency in multiplayer game scenarios. Players no longer need to manually copy and paste task content or repeatedly communicate verbally, significantly simplifying the workflow.

[0083] In an optional embodiment, the calendar interface also provides task management functionality, allowing players with the appropriate permissions to edit or delete tasks. Please refer to [link / reference]. Figure 3 When a player clicks or long-presses a target game task, the system can also display a delete control 33 and an edit control 34 in the calendar interface. The delete control 33 is used to trigger the deletion of the currently selected target game task, and the edit control 34 is used to trigger the editing of the content of the currently selected target game task. At this time, the player can modify the task's content information, execution time information, or executor information. Optionally, the display method of the delete control 33 and the edit control 34 is related to the player's permissions. For players with task management permissions (such as alliance managers, captains, etc.), both delete control 33 and edit control 34 can be displayed in full for easy task management; for players without task management permissions (such as alliance members, team members), only the share control 32 may be displayed. These players can only view and execute tasks, and do not have the right to modify or delete the tasks themselves, thus avoiding accidental operation or abuse of permissions.

[0084] Through this access control display mechanism, this embodiment provides a convenient task management entry point while ensuring clear operational boundaries for players with different roles, thus maintaining the order and security of the task system.

[0085] In an optional embodiment, the information processing method in the game further includes:

[0086] The area associated with the game task information displayed in the calendar interface displays a type identifier. The type identifier is used to represent the type of game task information, which includes one of the following: game tasks issued by the team leader that are related to the first game account, and game tasks issued by the system that are related to the first game account.

[0087] In the calendar interface, each game quest message, when displayed, can show a type identifier in its associated area (such as the left or right side of the game quest message or in the background). This type identifier is used to characterize the type of game quest message, allowing players to intuitively determine the source or affiliation of the quest through visual elements.

[0088] Type identification can take various visual forms, such as icons, labels, color markers, and text labels. Depending on the actual game design, types may include one of the following:

[0089] Tasks issued by the team leader: These are tasks issued by a second game account (such as a squad leader or alliance manager) that has a specific relationship with the first game account. These tasks typically involve teamwork and require player response and participation. The corresponding identifier can be a "team leader" icon, a "flag" symbol, or a background frame with a specific color.

[0090] System-issued tasks: These are tasks automatically generated by the game system and assigned to the first game account, such as daily activity tasks, limited-time event tasks, and story guidance tasks. These tasks are usually related to the player's personal growth or game progress. Their corresponding type identifier can be a "system" icon, a "gear" symbol, or a background frame of another color, or there may be no identifier.

[0091] For example, such as Figure 2 As shown, in the calendar interface, game missions marked with a "flag" icon correspond to missions issued by the team leader, while those without the "flag" icon correspond to missions issued by the system. This visual distinction allows players to quickly identify the source of a mission while browsing the calendar without clicking through to the mission details, enabling them to prioritize team or individual missions based on their needs.

[0092] It should be noted that the specific style, position, and display method of the type identifier can be flexibly adjusted according to the game interface design. In some implementations, the same task may have multiple types simultaneously (e.g., a system activity task issued by the team leader), in which case multiple identifiers can be displayed at the same time or a composite identifier can be used. Those skilled in the art can configure it according to actual needs, and these variations are all within the protection scope of this invention.

[0093] This embodiment enhances the information expression capability of the calendar interface by introducing a type identification function, enabling players to filter and identify tasks more efficiently. It is especially suitable for multiplayer game scenarios with diverse task types and complex sources, further improving the intuitiveness of task management.

[0094] In an optional embodiment, the information processing method in the game further includes:

[0095] Based on the multiple game task information to be displayed in the calendar interface, determine the display area of ​​the multiple game task information in the calendar interface;

[0096] Specifically, when the display areas of the first game task information and the second game task information overlap, the height of the display areas of the first game task information and / or the second game task information is adjusted according to a preset stacking rule.

[0097] When multiple game task information needs to be displayed simultaneously in the calendar interface, the system first determines an initial display area for each game task based on its execution time and content information. This display area defines the spatial position and size occupied by the task in the calendar interface, such as its start and end coordinates on the timeline and its corresponding height.

[0098] After determining the display areas for all game task information to be displayed, the system checks whether these display areas overlap. If the display areas of the first and second game task information intersect along the time axis (i.e., the height direction), it is determined that the two game task information areas overlap. If two overlapping display areas are rendered directly, the game task information will visually occlude each other, leading to decreased readability.

[0099] To resolve this overlap issue, the system adjusts the height of the display area for the first game task information and / or the second game task information according to preset stacking rules.

[0100] The display area for game task information is located in the taskbar of the calendar interface. Since the width of the taskbar in the calendar interface is fixed, when the height of the display area for game task information decreases, the length of text it can accommodate also decreases accordingly, which may affect the completeness of the display of game task information.

[0101] Stacking rules are a set of predefined layout algorithms used to redistribute the display area of ​​each task within a limited space to ensure that the display areas of all game task information do not overlap when finally displayed, while preserving the readability of the game task information as much as possible.

[0102] Specifically, the adjustments include resizing the display area (such as height compression) and / or shifting its position. That is, the display area of ​​game task information is dynamically adjusted through stacking rules to solve the visual overlap problem, thereby providing players with a clear and orderly calendar view. It should be noted that there can be various ways to implement the stacking rules, such as differentiated adjustments based on factors like task time priority, content length, and task type. In an optional embodiment, the preset stacking rules include: game task information with later time information has a higher display weight than game task information with earlier time information.

[0103] When two game task information items are stacked together, a principle is needed to determine which game task information to display first and which game task information to retain first.

[0104] The planned start time of a task is usually positively correlated with its release time. That is, tasks with earlier planned start times are often released first. Compared to tasks with later release times, tasks with earlier release times are already historical tasks, and players usually have enough time to browse and understand their specific content. Tasks with later release times are the newest tasks, and users usually have not browsed them or do not know their specific content. Therefore, in this embodiment, the later the planned start time, the higher the display weight is given to the target item. That is, the later the planned start time, the higher the display priority, and the more complete the display is, making it convenient for users to quickly and clearly obtain the specific content of the latest task.

[0105] In an optional embodiment, when the display weight of the second game task information is greater than the display weight of the first game task information, adjusting the height of the display area of ​​the first game task information and / or the second game task information includes:

[0106] The display area for the first game task information is highly compressed; however, the height of the display area for the second game task information remains unchanged.

[0107] As mentioned earlier, the preset stacking rules include giving higher display weight to game task information with later execution times. Based on this, when the display weight of the second game task information is greater than that of the first game task information (i.e., the execution time of the second game task information is later than that of the first game task information), the system adopts an adjustment strategy that prioritizes ensuring the integrity of high-weight tasks.

[0108] Specifically, the system only compresses the first game task information with lower weight (i.e., tasks executed earlier), while the second game task information with higher weight (i.e., tasks executed later) maintains its original display height to ensure that the latest or most urgent tasks can be presented to the player in the most complete form.

[0109] Please refer to Figure 4 This diagram illustrates how the height of the display area can be adjusted. Figure 4 (a) is a schematic diagram of the display area before adjustment. Assume the first game task information spans T1-T3 on the timeline, and its initial display area is H1; the second game task information spans T2-T4 on the timeline, and its initial display area is H2. H1 and H2 partially overlap on the timeline, with the overlapping area being P. According to the adjustment rules of this embodiment, since the display weight of the second game task information is greater than that of the first game task information, the system highly compresses H1, such as... Figure 4 As shown in (b), the adjusted region H1' is obtained, while the height of H2 remains unchanged. There is no longer any overlap between the adjusted region H1' and region H2, and the integrity and time alignment of region H2 are fully guaranteed.

[0110] In an optional embodiment, the display area for the first game task information is highly compressed, including:

[0111] Calculate the top-to-bottom spacing of the display areas for the first game task information and the second game task information to obtain the alternative height for the display area of ​​the first game task information; determine whether the alternative height is less than the preset minimum height; if so, set the height of the display area for the first game task information to the preset minimum height; if not, set the height of the display area for the first game task information to the alternative height.

[0112] This embodiment provides a specific algorithm for height compression of low-weight tasks (first game task information) based on the aforementioned differentiated compression scheme based on display weight. The maximum usable height of the first game task information is determined by calculating the top distance from the high-weight task (second game task information), and this height is set while ensuring a minimum height constraint.

[0113] Specifically, the distance between the top of the display area of ​​the first game task information and the top of the display area of ​​the second game task information is calculated, and this distance is determined as the alternative height of the display area of ​​the first game task information. The physical meaning of the alternative height is: the maximum height that the display area of ​​the first game task information can occupy without changing the position of the top of the display area of ​​the first game task information and without overlapping with the display area of ​​the second game task information.

[0114] Then, it is determined whether the candidate height is less than the preset minimum height. The preset minimum height is a configurable threshold used to ensure that the display area of ​​each task still retains enough display space for user recognition and interaction, even after compression, for example, 32 pixels.

[0115] If so, it means that the available space is too small to meet the basic visibility requirements. In this case, the minimum height constraint will be prioritized, keeping the top coordinates of the entry unchanged, while the height of its display area will be directly set to the preset minimum height.

[0116] If not, it means there is sufficient available space to meet basic visibility requirements. In this case, the existing space can be fully utilized, keeping the top coordinates of the item unchanged, while setting the height of its display area to the calculated alternative height.

[0117] This embodiment provides a simple and effective sequential compression method that prioritizes the integrity of high-weight tasks while allocating available space to low-weight tasks as much as possible, and ensures basic availability through minimum height constraints when space is insufficient. This algorithm is easy to implement, has low computational overhead, and is suitable for real-time interactive scenarios requiring rapid response.

[0118] It should be noted that the calculation method for the "top spacing" in this embodiment can be adjusted according to the coordinate system of the calendar view. For example, in a calendar view where the timeline extends vertically downwards, the top spacing is the vertical pixel distance between the starting points of two tasks. Those skilled in the art can flexibly implement this according to the actual interface design; this embodiment is merely illustrative.

[0119] In an optional embodiment, when the display weight of the second game task information is greater than the display weight of the first game task information, adjusting the height of the display area of ​​the first game task information and / or the second game task information further includes:

[0120] Determine the combined display areas of the first game task information and the second game task information to obtain the operation area; allocate a height ratio to the display areas of the first game task information and the second game task information according to the display weight, wherein the height ratio is positively correlated with the display weight; adjust the height of the display areas of the first game task information and the second game task information based on the height ratio and / or the height of the operation area.

[0121] This embodiment provides a flexible adjustment method that allows the display height of two tasks to be adjusted simultaneously and the available space to be allocated between them according to their display weights. It is especially suitable for scenarios where both tasks need to be compressed to a certain extent, such as when the available space is limited and compressing only the low-weight task cannot completely eliminate the overlap.

[0122] First, the combined display areas of the first and second game task information are determined, resulting in an operational area. This operational area refers to the total range covered by the initial display areas of the two tasks along the time axis, specifically the continuous area from the top of the first game task information to the bottom of the second game task information. Then, based on the display weights of the first and second game task information, a height ratio is assigned to each. The height ratio is positively correlated with the display weight; that is, the task with the higher the display weight is assigned a larger height ratio, thus occupying more display space in the operational area.

[0123] For example, the display weight of the first game task information is W. A The display weight of the second game task information is W. B And W B >W A The height ratio R of the first game task information. A The height ratio of the second game mission information R B It can be calculated in the following way:

[0124] R A =W A / (W A +W B);

[0125] R B =W B / (W A +W B );

[0126] R A +R B =1, and because W B >W A , there is R B >R A For example, if W A =1, W B =2, then R A =1 / 3, R B =2 / 3, meaning the second game task information will receive two-thirds of the height of the operating area.

[0127] After calculating the height ratio, based on the above height ratio and the height H of the operating area... T Calculate and adjust the height of the display area for each of the two tasks. Specifically:

[0128] After adjusting the display area for the first game mission information, the height HA' = R A ×H T ;

[0129] After adjusting the display area for the second game mission information, the height HB'=R B ×H T .

[0130] By allocating space according to weights, this embodiment eliminates overlapping display areas while giving high-weight tasks a larger display area, thus enabling them to display more complete content information. Low-weight tasks have a correspondingly reduced display area, but still receive space within the operating area commensurate with their weight. This proportional compression mechanism reflects differentiated treatment based on task importance and better aligns with players' cognitive needs in terms of information presentation weight allocation.

[0131] In an optional embodiment, adjusting the height of the display areas for the first game task information and the second game task information based on the height ratio and the height of the operating area includes:

[0132] For each game task information, calculate the compressed expected height based on the height ratio and the height of the operation area; determine whether the expected height is less than the preset minimum height; if so, set the height of the display area of ​​the current game task information to the preset minimum height; if not, set the height of the display area of ​​the current game task information to the expected height.

[0133] The calculation method for the expected height can refer to the relevant calculation method in the previous embodiment. After the expected height is calculated, it is determined whether the expected height is less than the preset minimum height. The preset minimum height is a configurable threshold used to ensure that each game task information can still retain enough display space for user recognition and interaction even after compression, such as 32 pixels.

[0134] If the expected height is greater than or equal to the preset minimum height, it means that the height after proportional compression is feasible, conforming to both the weight allocation principle and the minimum height requirement. In this case, the system sets the height of the display area for the game task information to the expected height; otherwise, it sets the height of the display area for the current game task information to the minimum height to ensure basic readability and interactivity.

[0135] This embodiment introduces a minimum height verification mechanism to allocate space according to weight ratios while setting an insurmountable bottom line for each task, ensuring that even in the most compact layout, each game task information still has basic readability and interactivity.

[0136] In an optional embodiment, after adjusting the height of the display area for the first game task information and / or the second game task information, the method further includes:

[0137] If the display areas of the first game task information and the second game task information still overlap, then shift the position of at least one display area of ​​the game task information along the time axis.

[0138] In the foregoing embodiments, the display areas of the first and second game task information have been height-adjusted through compression adjustments based on display weights (including sequential compression or proportional compression). However, in some cases, even after height adjustment, there may still be partial overlap between the display areas of the two tasks. This overlap may be caused by the following reasons:

[0139] When the height of a task is forcibly set to the preset minimum height, its display area may extend downwards, causing new overlap with the display areas of subsequent tasks;

[0140] When the text content of both tasks is quite long, the sum of the compressed heights still exceeds the height of the operating area;

[0141] When the timing of multiple tasks is too close together, simple high compression cannot completely separate the display areas of each task.

[0142] To address the residual overlap issue, this embodiment provides a translation adjustment mechanism as a supplementary measure after high compression. Specifically, after adjusting the height of the display areas for the first and second game task information, it checks again whether there is overlap between the display areas of these two tasks. If the detection result indicates that there is still overlap, the position of the display area of ​​at least one game task information is translated along the time axis until the overlap is completely eliminated.

[0143] During the translation adjustment process, the object and direction of translation can be flexibly selected according to the actual spatial situation. For example:

[0144] Prioritize shifting the display of tasks with lower weights to keep the positions of tasks with higher weights unchanged as much as possible;

[0145] Move the object in a direction with more space, for example, move it downwards when there is empty space below, and move it upwards when there is empty space above.

[0146] It should be noted that the translation adjustment can be implemented in conjunction with the aforementioned height compression embodiment, serving as the final guarantee step in the entire dynamic adjustment process. By using the adjustment method of compression followed by translation, a completely non-overlapping display effect can be achieved with minimal layout changes while meeting the minimum height constraint.

[0147] By using this rule as the default or preferred translation strategy, it is ensured that the output is not only geometrically neat, but also meets user needs in terms of the weighting of information presentation.

[0148] In an optional embodiment, after compressing the display area, when the game task information exceeds the display area, the game task information can also be compressed according to the height of the display area, including: determining the text length that can be accommodated according to the height of the display area to obtain the target text length; and compressing the game task information to the target text length.

[0149] When a game task message is detected to exceed its allocated display area, a compression strategy is automatically triggered. "Exceeding" here means that the minimum display height required to fully display the game task message exceeds the height of the display area, potentially causing text truncation or overflow. The display area for game task information is located in the taskbar of the calendar interface. Since the taskbar width in the calendar interface is fixed, the height of the display area required to fully display the game task information is linearly related to the text length of the game task information. First, the length of the game task information's text (e.g., the number of characters) is obtained. Then, combined with preset text rendering rules, the minimum display height required to fully render the game task information within a given fixed-width taskbar is calculated.

[0150] Once the compression strategy is triggered, the game task information will be compressed based on the space defined by the display area. Optionally, key fields such as time and core verbs will be prioritized for preservation and highlighting, while lengthy descriptions will be compressed.

[0151] In an optional embodiment, when compressing game task information, the game task information is compressed in segments based on available space.

[0152] To achieve flexible information compression, this embodiment introduces a tiered compression strategy, dividing the compression level into multiple levels based on the height of the display area, with each level corresponding to a different information presentation method. The core idea of ​​tiered compression is to display the content as completely as possible when space is ample, and to prioritize the preservation of key information (such as execution time) when space is limited, while secondary information is replaced by compression markers or completely hidden.

[0153] In one example, such as Figure 5 The diagram shown is a tiered compression diagram. Figure 5 (a) is the game mission information when fully displayed. Figure 5 (b) Game mission information when partially compressed and replaced with compression identifiers. Figure 5 (c) This shows game mission information that only displays time information. As you can see, the required display area height for game mission information varies depending on the level of compression, making it suitable for display areas of various heights (not less than the preset minimum height).

[0154] Optionally, compressed text in game mission information can be replaced or hidden using a preset compression flag.

[0155] For game mission information that has undergone adaptive processing (especially text compression), if some or all of its text content is replaced or hidden due to insufficient space, a compression flag will be displayed.

[0156] Compressed Marker Replacement: At the point where the text is truncated (usually at the end of the text), a preset compressed mark is used to replace the hidden text portion. The compressed mark can be a specific symbol (such as an ellipsis "...") or a specific icon.

[0157] Compression markers become part of the content, indicating the cutoff point of information and providing users with information on the completeness of the game quest, while guiding users to subsequent interactive actions (such as clicking to expand details), thus saving screen space while maintaining interactivity.

[0158] Hide and show: First, ensure that even in the most compact layout, users can still clearly know the specific planned time of the task. The complete hidden text can be obtained in the pop-up or details page through subsequent user interactions (such as clicking or hovering).

[0159] In one example, such as Figure 6 The diagram shows a comparison of the game task information layout before and after adjustments. Figure 6 (a) shows the layout of the stacked game task information before the game task information is adjusted. Specifically, it includes W1, W2, and W3. W1 and W2 overlap to some extent. From the time corresponding to each game task information, it can be seen that the planned time of W1 is earlier than that of W2. Figure 6 (b) in the diagram is a schematic of the game task information layout without stacking after adjustment. Figure 6 A comparison of (a) and (b) shows that for W1, some of the text content is compressed and the compression mark "..." is used to replace the compressed part. The compression effect is to reduce the height required to display one line of text content. For W2, due to insufficient space, its text content is completely hidden.

[0160] In an optional embodiment, the information processing method in the game further includes:

[0161] In response to the user's touch operation on the compressed game task information, the game task information is fully displayed in the task details interface.

[0162] To address the issue of compressed text content, this embodiment also provides an information restoration mechanism to respond to users' needs for a complete view of incomplete game task information. For example... Figure 3 As shown, the calendar interface contains multiple game mission messages with compressed text (e.g., "The Fight!", "Compet", "Here Comes...", etc.). Figure 3 As shown, when a user clicks (touch operation) on such a compressed item (such as "The Fight!"), the system will immediately respond to the operation and pop up the mission details interface, which fully displays all the information about the game mission.

[0163] In an optional embodiment, the calendar interface can integrate a real-time time indicator function to enhance the user's perception of the relationship between task time and the current time. Specifically, it continuously acquires the current time of the device or server, converts the current time into corresponding coordinates within the taskbar, and draws a time indicator line at these coordinates that is perpendicular to the time axis and horizontally runs through the taskbar or multiple side-by-side taskbars for the current date. Figure 2As shown, a red dashed line, distinct from the taskbar background, serves as a time indicator. This time indicator shows the current moment and moves as time changes.

[0164] This time indicator line allows users to visually determine the stage of each task. Specifically, if the entire information for a game task on the current date is above the line, it means the task's planned time is earlier than the current time, indicating that the task has been completed or has expired. If the time indicator line crosses the game task information, it means the current time is within the task's planned time period (for time-slot tasks) or the planned time is earlier than the current time (for point-in-time tasks). If the entire information for a game task is below the line, it means the task's planned time is later than the current time.

[0165] This embodiment introduces a dynamic time indicator line, establishing an intuitive visual connection between static tasks and flowing real time, helping users grasp the time status of tasks and enhancing the readability of the calendar interface.

[0166] Optionally, in the calendar interface, the taskbar for the current date is displayed differently than that for other dates. For example, as shown... Figure 2 As shown, the taskbar for the current date (August 4th) is highlighted.

[0167] Each game task occupies a predefined rectangular area on the calendar interface, which is its initial display area. This initial display area is usually pre-calculated based on the task's attributes (such as scheduled time and content length) and preset rendering rules. These preset rendering rules include, but are not limited to, specified font, font size, line height, character spacing, and taskbar padding.

[0168] Reference Figure 7 The diagram illustrates an information processing method in a game according to an embodiment of the present invention. This method can be executed by an information processing device in the game. The display system for game task information in the calendar can be implemented in hardware and / or software. The information processing device in the game can be configured in an electronic device.

[0169] This method provides a graphical user interface (GUI) through a second terminal (such as a smartphone, tablet, or personal computer), which displays at least a portion of a virtual scene. This virtual scene can be a 3D environment, map interface, or battle scene within a game. The second terminal corresponds to a second game account, i.e., the quest issuer, such as an alliance manager, squad leader, or other player with quest-issuing authority.

[0170] like Figure 7 As shown, the method may specifically include the following steps:

[0171] S701, in response to a task release trigger operation, displays the task editing interface through a graphical user interface.

[0172] The task release trigger is the initial action that initiates the task creation process for a player. This trigger can be implemented in various ways, such as:

[0173] When a player clicks on a virtual plot of land (such as a castle, outpost, or resource point) in a virtual scene, the system recognizes that plot as the target location and automatically pops up a task creation option;

[0174] Players can directly enter the task creation process by clicking the "Publish Task" control (such as a floating button or menu option) in the graphical user interface;

[0175] Players can click the "New Task" button in the calendar interface, or select "Copy and Create" based on an existing task.

[0176] When any of the above-mentioned triggering actions are detected, a task editing interface will be displayed on the graphical user interface. This editing interface is used for players to input or select relevant information about the task to be issued, and typically includes multiple input areas or option controls, such as a time selector, a content input box, and an executor selection list.

[0177] S702, In response to an editing operation on the task editing interface, determine the game task information, which includes time information, content information, and executor information.

[0178] After the task editing interface is displayed, players can perform various editing operations to define the information for the upcoming game task. Editing operations can include:

[0179] Set time information: Players can set the execution time of the task through the time selector. It can be a specific time point (such as "20:00") or a time period (such as "14:00-16:00").

[0180] Input content information: Players fill in the task description text in the content input box, such as task objectives, location, precautions, reward description, etc.;

[0181] Assigned executor information: Players select one or more executors from their friends list, alliance member list, or recent contacts, which are the game accounts assigned to complete the task.

[0182] During or after the player completes the editing process, the game task information to be published is determined based on the player's input. This game task information includes at least the aforementioned time information, content information, and executor information, and may also include other additional information, such as the identity of the task publisher, task type tags, and associated virtual scene location.

[0183] S703, in response to the task release confirmation operation, sends the game task information to the executor so that the game task information is displayed in the executor's corresponding calendar interface.

[0184] After players have finished editing the quest information, they can perform a confirmation action in the quest editing interface, such as clicking the "Publish," "Confirm," or "Send" button. In response to this confirmation, the system will send the finalized game quest information to the designated player's game terminal via the game server.

[0185] In an exemplary implementation scenario, Figure 8 The diagram illustrates a task editing interface provided by an embodiment of the present invention. This interface can be applied to a second terminal (i.e., the terminal used by the task publisher) for players with task publishing permissions (such as alliance managers or squad leaders) to create and publish game tasks.

[0186] like Figure 8 As shown, the task editing interface is themed "Alliance Announcement" and clearly distinguishes different information areas for the task, making it easy for players to quickly fill in and confirm task content. Specifically, the interface includes: execution time setting area 81, execution member setting area 82, (task) content input area 83, and release confirmation control 84.

[0187] like Figure 8 As shown, the execution time setting area 81 includes an "Execution Time" selector for players to set the execution time of a task. In this example, the execution time includes the date and the specific time. Players can select the date to execute the task by clicking the date selector (e.g., "08 / 23") and set the specific execution time by using the time selector (e.g., "15:05"). This setting corresponds to the "Time Information" in the game task information, determining the timeline position of the game task in the calendar interface.

[0188] The "Executor Members" option is located in the Executor Member Settings area 82. In this example, the default option is "All," meaning the task will be sent to all members of the alliance or squad. Players can also click on this area to select specific executors from the member list (such as specifying only certain team members), thus achieving precise control over the scope of task reception. This setting corresponds to the "Executor Information" in the game's task information, determining which players' calendar interfaces will receive the task.

[0189] The content input area 83 has two text input boxes, one for entering the task title and the other for entering detailed content.

[0190] Title input box: Labeled as "Title", with a maximum of 30 characters, used to concisely summarize the core objective of the task, such as "siege".

[0191] Content input box: labeled "Content", limited to a maximum of 500 characters, used to fill in a detailed description of the task, such as assembly requirements, tactical arrangements, precautions, reward descriptions, etc.

[0192] These two input boxes together constitute the game task information, determining the specific text content displayed for the task in the calendar interface.

[0193] At the bottom of the calendar interface is a "Send" button, which serves as a task release confirmation control. After the player completes the filling in and selection of the above information, clicking this button will trigger the task release confirmation operation. In response to this operation, the system will send the confirmed game task information (including time information, executor information, and content information) to the designated executor and generate the corresponding game task information in the executor's calendar interface.

[0194] This interface design allows task creators to complete all operations—from setting the time and assigning personnel to filling in the content—in a unified view, eliminating the need to switch between multiple interfaces and significantly improving the convenience and efficiency of task creation. Meanwhile, the character limit for the input boxes (30 characters for the title, 500 characters for the content) helps control the displayed length of game task information, providing a solid foundation for subsequent layout optimization of the calendar interface (such as the aforementioned stacking rules and text compression).

[0195] It should be noted that, Figure 8 The interface shown is for illustrative purposes only and can be adjusted according to game style and functional requirements in actual applications. For example, the execution time can support time period selection (such as "14:00-16:00"), the execution members can support multi-level filtering (such as grouping by alliance position or by team), and the content input box can support rich text formatting, etc. These modifications all fall within the protection scope of this invention.

[0196] Specifically, after a task is published, for each designated executor, the system pushes the game task information to their corresponding first terminal and generates a corresponding game task information in the first terminal's calendar interface. The display method of this game task information is consistent with the aforementioned embodiment, including execution time information and content information, and is displayed according to the executor's calendar view layout. The executor can view the task in their own calendar interface and perform corresponding trigger operations as needed (such as viewing details, jumping to a different scene, sharing the task, etc.).

[0197] For example, suppose team leader "Zhang San" clicks on the "K Castle" plot on the alliance map on a second terminal, and the system pops up a task editing interface. In this interface, "Zhang San" sets the task time to "20:00," enters the message "Attack K Castle, please assemble in advance," and selects "Li Si" and "Wang Wu" as executors from the member list. After clicking the "Publish" button, the system sends the task information to Li Si and Wang Wu's first terminals. Li Si opens his calendar interface and sees the game task information "Attack K Castle at 20:00." Clicking on the game task information allows him to view details or jump to the K Castle area.

[0198] Through the steps described above, this embodiment provides task publishers with a complete task creation and distribution process, enabling managers to easily formulate task plans, assign executors, and ensure that task information is accurately and promptly delivered to the executors' calendar interfaces. This design, in conjunction with the task viewing and triggering operation process on the first terminal side, forms a closed-loop chain from task publication to task execution, greatly improving the efficiency and experience of in-game team collaboration.

[0199] It should be noted that the specific form of the task release trigger operation, the layout design of the task editing interface, and the method of specifying the executor information can all be flexibly configured according to the actual needs of the game. This embodiment is only for illustrative purposes. In some implementations, the system can also provide advanced functions such as task templates, quick fill, and batch release, all of which fall within the protection scope of this invention.

[0200] In one optional embodiment, the task release triggering operation includes one of the following:

[0201] Triggering operations for any virtual plot of land in a virtual scene;

[0202] Responds to a triggered action on a task publishing control in a graphical user interface.

[0203] The service release trigger operation can be implemented through multiple interaction methods to adapt to different players' operating habits and game scenario requirements. This embodiment provides two trigger methods, corresponding to scene interaction and interface control-based entry points, respectively.

[0204] This trigger method allows players to initiate a quest creation process by directly performing a trigger action on any virtual plot within the virtual environment (such as a game map). Virtual plots can be any interactive location in the game world, such as castles, strongholds, resource points, battlefield areas, and rally points. The trigger action can be performed by clicking, double-clicking, long-pressing the plot, or right-clicking to bring up a menu and selecting the "Create Quest" option.

[0205] When the system detects that a player has performed the aforementioned triggering action on a virtual plot of land, it automatically identifies that plot as the target location and associates it with the task. Subsequently, the system displays a task editing interface in the graphical user interface, where the plot's name or coordinates can be pre-filled, allowing players to quickly confirm the task location. This triggering method is particularly suitable for tasks requiring a specific location, such as "siege," "defense," and "resource gathering," eliminating the need for players to manually input location information, resulting in a shorter operation path and a more intuitive experience.

[0206] In response to a trigger action on the task posting control in the graphical user interface, players initiate the task creation process by clicking a fixed control in the graphical user interface. The task posting control can be located in the sidebar, bottom menu, floating button, or system menu of the game's main interface, and is usually presented as text or icons such as "Post Task," "Create Announcement," or "Create Event."

[0207] When a player clicks the task posting control, the system directly displays the task editing interface, regardless of whether a specific plot is selected in the current scene. This triggering method is suitable for tasks that do not require specifying a specific location, such as announcement-type tasks like "All gather at 8:00 PM tonight" or "Alliance activities begin tomorrow."

[0208] In an optional embodiment, the information processing method in the game further includes:

[0209] The graphical user interface displays the calendar interface corresponding to the second game account, which contains game task information issued by the second game account. The second game account is the game account corresponding to the second terminal.

[0210] In the aforementioned embodiment, the second terminal (task publisher) creates and publishes game task information through a task editing interface. This task information is sent to the designated executor and displayed in the executor's calendar interface. However, in actual game collaboration scenarios, the publisher also needs to have a global grasp of the tasks they publish, such as checking which tasks have been published, confirming whether the task execution time is reasonable, and reviewing historically published tasks. Therefore, this embodiment introduces a calendar interface on the second terminal side, enabling the publisher to view their published tasks in a view similar to that of the executor.

[0211] Specifically, in the graphical user interface of the second terminal, the system can also display a calendar interface. This calendar interface has a similar layout and interaction method to the calendar interface on the first terminal, but its content focuses on game task information published by the second game account. That is to say, this calendar interface only displays tasks created by the second game account (i.e., the currently logged-in publisher account) and successfully sent to the executor, and does not display tasks published by other players or system tasks.

[0212] The calendar interface on the publisher side can be displayed in response to specific viewing actions, such as when a player clicks on the "My Posts" or "My Created Tasks" entry points on the main interface, or switches to the "Publisher View" within the existing calendar interface. When a player performs such a viewing action, the system retrieves the list of tasks posted by the second game account from the server and presents each game task information in chronological order on the calendar interface. Each game task information includes at least execution time information and content information, and its display method is consistent with the calendar interface on the executor side, such as being arranged by timeline and allowing users to click to view details.

[0213] By providing task publishers with a personal calendar view, they can centrally view and manage all the game task information they publish.

[0214] In an optional embodiment, the information processing method in the game further includes:

[0215] In response to a third triggered operation on the target game task in the calendar interface corresponding to the second game account, control the target game task to enter the edit state; in response to the edit operation on the target game task, update the target game task.

[0216] In the aforementioned embodiment, the calendar interface of the second terminal (task publisher) centrally displays all game task information it has published. However, in actual game collaboration, task arrangements may need to be adjusted based on changes in the battle situation, player feedback, or the publisher's own considerations. For example, a siege task originally scheduled for 20:00 may need to be moved forward to 19:30, or the task description may need to be supplemented with new tactical requirements. Therefore, this embodiment introduces a task editing function in the calendar interface on the publisher's side, allowing the publisher to directly modify published tasks.

[0217] Specifically, you can refer to Figure 3 In the calendar interface corresponding to the second game account, each game task published by that account is presented visually. When the publisher wants to modify a published task, they can perform a third trigger operation on the target game task. This third trigger operation can be an interaction method specific to the editing function, for example:

[0218] After clicking on the game task information, select the "Edit" option in the pop-up operation panel; double-click the game task information to enter edit mode; long-press the game task information to bring up the shortcut menu and select "Edit"; click the "Edit" icon (such as a pencil-shaped icon) on the right side of the game task information.

[0219] When the system detects the aforementioned third trigger operation, it will control the target game task to enter edit mode. In edit mode, task entries can be converted into editable input controls, such as replacing the originally statically displayed time and content text with a time selector or text input box, for the publisher to modify. Alternatively, the system can pop up a separate task editing interface, which is integrated with... Figure 8 The task creation interface shown is similar, but it is pre-filled with the current information of the task, making it convenient for the publisher to make adjustments based on this.

[0220] This embodiment introduces a task editing function, providing task publishers with flexible and dynamic adjustment capabilities, enabling them to optimize task arrangements at any time according to actual conditions and ensure the accuracy of task information.

[0221] In an optional embodiment, the information processing method in the game further includes:

[0222] In response to the deletion operation of the target game task in the calendar interface corresponding to the second game account, the target game task is deleted from the calendar interface corresponding to both the second game account and the executor.

[0223] In some cases, the publisher may need to delete a task, such as when the task is canceled for any reason (e.g., event postponement, change in the battle situation); when the information was entered incorrectly when the task was posted and needs to be recreated; or when the task has expired.

[0224] To this end, this embodiment introduces a task deletion function in the calendar interface on the publisher's side, enabling the publisher to completely remove published tasks from the calendar interfaces of all relevant users.

[0225] In the calendar interface corresponding to the second game account, each game task information posted by that account is presented in a visual format. When the poster wishes to delete a posted task, they can perform the deletion operation on the target game task. The deletion operation can be achieved through several interactive methods, such as: clicking on the game task information and selecting the "Delete" option in the pop-up operation panel; long-pressing the game task information, bringing up the shortcut menu, and then selecting "Delete"; or clicking the "Delete" icon (such as a trash can-shaped icon) on the right side of the game task information.

[0226] This embodiment introduces a task deletion function, providing task publishers with complete task lifecycle management capabilities, enabling them to flexibly adjust or cancel published tasks according to actual circumstances, and ensuring the accuracy and timeliness of task information.

[0227] In an optional embodiment, the information processing method in the game further includes:

[0228] In response to a drag operation on the target game task in the calendar interface corresponding to the second game account, update the display position of the target game task in the calendar interfaces corresponding to the second game account and the executor.

[0229] Editing typically requires navigating to a separate editing interface, resulting in a lengthy process and making it difficult to intuitively perceive changes before and after time adjustments. To further enhance the convenience and intuitiveness of task management, this embodiment introduces a drag-and-drop adjustment function into the calendar interface on the publisher's side.

[0230] The method may include the following steps:

[0231] In the calendar interface corresponding to the second game account, each game task information published by that account is presented visually in the task bar for the corresponding date and time. When the publisher wants to adjust the time of a published task, they can drag the target game task. The drag operation is usually triggered in the following way: the publisher long-presses the game task information, and after the item enters a draggable state, they keep pressing and move their finger or cursor to drag the game task information to a new position.

[0232] The calendar interface includes at least two taskbars, in which game task information is displayed, with each taskbar corresponding to a date. In this embodiment, the layout structure of the calendar interface can be further expanded to support the parallel display and management of multiple dates. Specifically, the calendar interface includes at least two side-by-side taskbars, each predefined and corresponding to a specific date, with all game task information displayed in the taskbar corresponding to the date of its scheduled time.

[0233] When a user drags an item across its display area, the system continuously tracks the drag operation. When the user releases the drag, the system captures the screen position of the release point and executes at least one of the following update logics based on that position information:

[0234] Update planned time: Based on the coordinates of the release point on the time axis, map it to a specific time point or time period, and update the planned time of the target entry with this time.

[0235] Update the taskbar: Determine which date taskbar the release point corresponds to and move the target entry to the new taskbar.

[0236] For details, please refer to Figure 9 , Figure 9 This is an illustration of how to update task times by dragging and dropping in a calendar interface, such as... Figure 9 As shown, the calendar interface includes three taskbars, corresponding to August 4th, August 5th, and August 6th respectively. For a task in the August 4th taskbar, "Compete For The Stronghold, 10:00~11:00," if the user drags horizontally and stops at the August 5th taskbar, the task will be moved to the August 5th taskbar. Because it's a horizontal drag, the mapped time point on the timeline remains the same, so the scheduled time in the task remains unchanged; only the execution date changes. Conversely, if it's not a horizontal drag, the mapped time point on the timeline will change, and the scheduled time in the task will also change accordingly.

[0237] This embodiment uses a drag-and-drop interaction paradigm to integrate task modification (including changing time and date) operations that might otherwise require multiple steps into a single, user-friendly drag-and-drop action, significantly improving the flexibility and efficiency of schedule management.

[0238] In an optional embodiment, users with task management permissions (such as team leaders or alliance administrators) can manage tasks using the aforementioned task management functions (editing, dragging, etc. based on operation icons). Upon completion of task editing, the task can also be synchronously updated to associated users (such as squad members or alliance members) so that team members or members can receive the latest published tasks. The latest published tasks typically include a designated identifier, such as... Figure 3 , Figure 9 As shown, on August 4th (the current date), the newly released tasks are marked with a "NEW" icon, allowing team members to intuitively and quickly find the latest tasks and improve information acquisition efficiency. It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this embodiment.

[0239] Reference Figure 10 The diagram illustrates an information processing device for a game according to an embodiment of the present invention. This device provides a graphical user interface (GUI) via a first terminal, which displays at least a portion of a virtual scene and may specifically include the following modules:

[0240] The calendar interface display module 101 is used to respond to the task viewing operation and display the calendar interface corresponding to the first game account through the graphical user interface. The calendar interface is used to display game task information related to the first game account. The game task information includes execution time information and content information.

[0241] The execution module 102 is used to execute game processing logic corresponding to the trigger operation in response to the trigger operation of the target game task in the calendar interface.

[0242] This invention provides an information processing device for games. By using this information processing device, the steps in the aforementioned information processing method embodiments of games that provide a graphical user interface through a first terminal can be implemented, and the device has the technical effects corresponding to the method embodiments, which will not be elaborated here.

[0243] Reference Figure 11 The diagram illustrates an information processing device for a game according to an embodiment of the present invention. A graphical user interface is provided via a second terminal, which displays at least a portion of a virtual scene. Specifically, the graphical user interface may include the following modules:

[0244] The editing interface display module 111 is used to display the task editing interface through the graphical user interface in response to the task release trigger operation;

[0245] The game task information determination module 112 is used to determine game task information in response to the editing operation of the task editing interface. The game task information includes time information, content information and executor information.

[0246] The task sending module 113 is used to send the game task information to the executor in response to the task release confirmation operation, so as to display the game task information in the calendar interface corresponding to the executor.

[0247] This invention provides an information processing device for games. By using this information processing device, the steps in the aforementioned information processing method embodiments for games that provide a graphical user interface through a second terminal can be implemented, and the device has the technical effects corresponding to the method embodiments, which will not be elaborated here.

[0248] It should be noted that the module division in the information processing devices for various games provided in the above embodiments is illustrative and only represents a logical functional division. In actual implementation, other division methods may also be used. Furthermore, the functional modules in the various embodiments of this invention can be integrated into a single processor, exist as separate physical entities, or consist of two or more modules integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0249] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the embodiments of the present invention can be embodied in the form of a computer program product, which is stored in a computer storage medium and includes several instructions to cause an electronic device or processor to execute all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned computer storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0250] Furthermore, the information processing device and the information processing method provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0251] Reference Figure 12 The diagram illustrates an electronic device according to an embodiment of the present invention. Figure 12 As shown, the electronic device in this embodiment of the invention includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the above-described information processing method embodiment of the game. Alternatively, when the processor executes the computer program, it implements the functions of each module in the above-described information processing device embodiment of the game.

[0252] For example, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which can be used to describe the execution process of the computer program in the electronic device.

[0253] The electronic device may be a desktop computer, a cloud server, or other computing device. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 12 This is merely one example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0254] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0255] The memory can be an internal storage unit of the electronic device, such as a hard drive or RAM. Alternatively, it can be an external storage device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory can include both internal and external storage units. The memory is used to store the computer program and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output.

[0256] This invention also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the information processing method in the game as described in the foregoing embodiments.

[0257] This invention also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the information processing method in the game as described in the foregoing embodiments.

[0258] This invention also discloses a computer program product that, when run on a computer, causes the computer to execute the information processing methods in the game described in the foregoing embodiments.

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

Claims

1. An information processing method in a game, characterized in that, The method includes providing a graphical user interface (GUI) via a first terminal, the GUI displaying at least a portion of a virtual scene, the method comprising: In response to the task viewing operation, the calendar interface corresponding to the first game account is displayed through the graphical user interface. The calendar interface is used to display game task information related to the first game account. The game task information includes execution time information and content information. In response to a trigger operation on a target game task in the calendar interface, the game processing logic corresponding to the trigger operation is executed.

2. The method according to claim 1, characterized in that, The method further includes: In response to the task type selection operation, the game task information corresponding to the target task type is displayed in the calendar interface; The target task type includes at least one of the following: a game task related to the first game account issued by the second game account, or a game task related to the first game account issued by the system, wherein the second game account and the first game account are allies.

3. The method according to claim 1, characterized in that, The step of responding to a trigger operation on a target game task in the calendar interface and executing game processing logic corresponding to the trigger operation includes: In response to a first trigger operation on the target game task in the calendar interface, the calendar interface is closed, and the graphical user interface is controlled to display the virtual scene area corresponding to the target location, wherein the target location is the location associated with the target game task.

4. The method according to claim 3, characterized in that, The step of responding to a first trigger operation on a target game task in the calendar interface, closing the calendar interface, and controlling the graphical user interface to display the virtual scene area corresponding to the target location includes: In response to an operation to view details of a target game task in the calendar interface, a task details interface is displayed, which includes a go-to control; In response to a trigger operation on the go control, the calendar interface is closed, and the graphical user interface is controlled to display the virtual scene area corresponding to the target location.

5. The method according to claim 1, characterized in that, The step of responding to a trigger operation on a target game task in the calendar interface and executing game processing logic corresponding to the trigger operation includes: In response to a second triggered operation on the target game task in the calendar interface, the target game task is shared to the target platform.

6. The method according to claim 1, characterized in that, The method further includes: The area associated with the game task information displayed in the calendar interface displays a type identifier, which is used to characterize the type of the game task information. The type includes one of the following: game tasks issued by the team leader and related to the first game account, and game tasks issued by the system and related to the first game account.

7. The method according to claim 1, characterized in that, The method further includes: Based on the multiple game task information to be displayed in the calendar interface, determine the display area of ​​the multiple game task information in the calendar interface; When the display areas of the first game task information and the second game task information overlap, the height of the display areas of the first game task information and / or the second game task information is adjusted according to a preset stacking rule.

8. The method according to claim 7, characterized in that, The preset stacking rules include: game task information with later time information has a higher display weight than game task information with earlier time information.

9. The method according to claim 8, characterized in that, When the display weight of the second game task information is greater than the display weight of the first game task information, adjusting the height of the display area of ​​the first game task information and / or the second game task information includes: The display area for the first game task information is highly compressed; The height of the display area for the second game task information remains unchanged.

10. The method according to claim 8, characterized in that, When the display weight of the second game task information is greater than the display weight of the first game task information, adjusting the height of the display area of ​​the first game task information and / or the second game task information includes: The combined display areas of the first game task information and the second game task information are determined to obtain the operation area; The display areas of the first game task information and the second game task information are allocated a height ratio according to the display weight, wherein the height ratio is positively correlated with the display weight; Based on the height ratio and the height of the operating area, adjust the height of the display area for the first game task information and / or the second game task information.

11. An information processing method in a game, characterized in that, The method includes providing a graphical user interface via a second terminal, the graphical user interface displaying at least a portion of the virtual scene, the method comprising: In response to a task release trigger operation, the task editing interface is displayed through the graphical user interface. In response to an editing operation on the task editing interface, game task information is determined, which includes time information, content information, and executor information; In response to the task release confirmation operation, the game task information is sent to the executor so that the game task information is displayed in the executor's corresponding calendar interface.

12. The method according to claim 11, characterized in that, The task release trigger operation includes one of the following: Triggering operation for any virtual plot in the virtual scene; In response to a triggered operation on the task publishing control in the graphical user interface.

13. The method according to claim 11, characterized in that, The method further includes: The graphical user interface displays a calendar interface corresponding to the second game account, which contains game task information published by the second game account. The second game account is the game account corresponding to the second terminal.

14. The method according to claim 13, characterized in that, The method further includes: In response to a third trigger operation on the target game task in the calendar interface corresponding to the second game account, the target game task is controlled to enter the editing state; In response to an edit operation on the target game task, update the target game task.

15. The method according to claim 13, characterized in that, The method further includes: In response to the deletion operation of the target game task in the calendar interface corresponding to the second game account, the target game task is deleted from the calendar interface corresponding to the second game account and the executor.

16. The method according to claim 13, characterized in that, The method further includes: In response to a drag operation on the target game task in the calendar interface corresponding to the second game account, update the display position of the target game task in the calendar interface corresponding to the second game account and the executor.

17. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the information processing method in the game as described in any one of claims 1-16.

18. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the information processing method in the game as described in any one of claims 1-16.

Images