Login prompting method and device, equipment, storage medium and program product

Abstract

The invention discloses a login prompting method and device, equipment, a storage medium and a program product, and belongs to the field of human-computer interaction. The method is applied to a server, and comprises the following steps: acquiring an offline interaction event of a user account under the condition that a client requests to log in the user account; processing the offline interaction event to obtain offline interaction data of the offline interaction event; generating prompt data of the to-be-prompted event based on the offline interaction data of the to-be-prompted event; when the user account is in the login state, caching prompt data of the to-be-prompted event; and when the user account is in the login completion state, sending the cached prompt data to the client. According to the scheme, under the condition that the user account logs in the client again after being offline, the server can send the prompt data corresponding to the to-be-prompted event processed by the user account in the login period to the client, so that the user account can be normally prompted at the client after login is completed.

Description

Technical Field

[0001] The present application relates to the field of human-computer interaction, and in particular to a login prompt method, device, equipment, storage medium and program product. Background Art

[0002] Players can log in to the game again after being offline. During the login period, it is usually necessary to load data of various offline interaction events during the player's offline period, such as: friend gifts, intimacy applications, offline chats, etc.

[0003] In the related art, during the player login, the data of offline interaction events needs to be processed. After all the data of offline interaction events are processed, the player data can be updated to the latest state. Before the player login is completed, the notification message sent by the server to the client will be blocked. Only when the player login is completed, the server and the client can communicate normally.

[0004] However, when processing some offline interactive events, players usually hope that the client can give players some prompts for feedback after processing these offline interactive events, and these prompt data for feedback need to be sent to the client by the server in the form of notification messages. The solution of the related art will cause the notification message of the prompt data during the player's login to be blocked and sent, resulting in the client being unable to give prompts normally. Summary of the invention

[0005] The present application provides a login prompt method, device, equipment, storage medium and program product. The technical solution is as follows:

[0006] According to one aspect of the present application, a login prompt method is provided, the method is applied to a server, and the method includes:

[0007] When a client requests to log in to a user account, obtaining offline interaction events of the user account; the offline interaction events are events that occur during a time period when the user account is offline;

[0008] Processing the offline interaction event to obtain offline interaction data of the offline interaction event;

[0009] Based on the offline interaction data of the event to be prompted, generating prompt data of the event to be prompted; the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client;

[0010] When the user account is in a login state, the prompt data of the event to be prompted is cached; and when the user account is in a login completion state, the cached prompt data is sent to the client.

[0011] According to another aspect of the present application, a login prompt device is provided, the device comprising:

[0012] An acquisition module, configured to acquire offline interaction events of a user account when a client requests to log in to the user account; the offline interaction events are events that occur during a time period when the user account is offline;

[0013] A processing module, used to process the offline interaction event to obtain offline interaction data of the offline interaction event;

[0014] A generating module, configured to generate prompting data of the event to be prompted based on the offline interaction data of the event to be prompted; the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client;

[0015] The sending module is used to cache the prompt data of the event to be prompted when the user account is in a login state; and to send the cached prompt data to the client when the user account is in a login completion state.

[0016] According to another aspect of the present application, a computer device is provided, the computer device comprising: a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the login prompt method as described above.

[0017] According to another aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and the computer program is loaded and executed by a processor to implement the login prompt method as described above.

[0018] According to another aspect of the present application, a computer program product is provided, which includes computer instructions, the computer instructions are stored in a computer-readable storage medium, and a processor obtains the computer instructions from the computer-readable storage medium, so that the processor loads and executes to implement the login prompt method as described above.

[0019] The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least:

[0020] During the login period of the user account, the server generates prompt data of the event to be prompted based on the offline interaction data of the event to be prompted, wherein the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client, and caches the prompt data of the event to be prompted when the user account is in the login state; and sends the cached prompt data to the client when the user account is in the login completion state. Accordingly, the server can successfully send the prompt data corresponding to the event to be prompted processed by the user account during the login period to the client, so that the prompt can be normally performed on the client after the user account login is completed. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 A structural block diagram of a computer system provided by an exemplary embodiment is shown;

[0023] Figure 2 A schematic diagram of a login prompt method provided by an exemplary embodiment is shown;

[0024] Figure 3 A flowchart of a login prompt method provided by an exemplary embodiment is shown;

[0025] Figure 4 A flowchart of a login prompt method provided by an exemplary embodiment is shown;

[0026] Figure 5 A flowchart of a login prompt method provided by an exemplary embodiment is shown;

[0027] Figure 6 A flowchart of a login prompt method provided by an exemplary embodiment is shown;

[0028] Figure 7 A schematic diagram of a login prompt method provided by an exemplary embodiment is shown;

[0029] Figure 8 A schematic diagram of a login prompt method provided by an exemplary embodiment is shown;

[0030] Fig. 9 A schematic diagram of a login prompt method provided by an exemplary embodiment is shown;

[0031] Fig.10A schematic diagram of a login prompt method provided by an exemplary embodiment is shown;

[0032] Fig.11 A structural block diagram of a login prompt device provided by an exemplary embodiment is shown;

[0033] Fig.12 A structural block diagram of a computer device provided by an exemplary embodiment is shown. DETAILED DESCRIPTION

[0034] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0035] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0036] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0037] It should be noted that before collecting relevant user data (such as user account data, interaction data, prompt data, status data) and during the process of collecting relevant user data, this application can display a prompt interface, pop-up window or output voice prompt information. The prompt interface, pop-up window or voice prompt information is used to prompt the user that its relevant data is currently being collected, so that this application only starts to execute the relevant steps of obtaining user-related data after obtaining the user's confirmation operation on the prompt interface or pop-up window, otherwise (that is, when the user's confirmation operation on the prompt interface or pop-up window is not obtained), the relevant steps of obtaining user-related data are terminated, that is, the user's relevant data is not obtained. In other words, all user data collected by this application are collected with the user's consent and authorization, and the collection, use and processing of relevant user data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0038] First, the nouns involved in the embodiments of the present application are briefly introduced:

[0039] Virtual environment: is a virtual environment displayed or provided by the client when it is running on the terminal. The virtual environment can be a simulation of the real world, a semi-simulated and semi-fictitious three-dimensional world, or a purely fictitious three-dimensional world. The virtual environment can be any one of a two-dimensional virtual environment, a 2.5-dimensional virtual environment, and a three-dimensional virtual environment. Optionally, the virtual environment is also used for a virtual environment battle between at least two virtual characters, and there are virtual resources in the virtual environment that can be used by at least two virtual characters. Optionally, the virtual environment includes symmetrical lower left corner area and upper right corner area, and virtual characters belonging to two hostile camps occupy one of the areas respectively.

[0040] Virtual character: refers to an movable object in a virtual environment. The movable object may be at least one of a virtual person, a virtual animal, and a cartoon character. Optionally, when the virtual environment is a three-dimensional virtual environment, the virtual character may be a three-dimensional virtual model, and each virtual character has its own shape and volume in the three-dimensional virtual environment, and occupies a part of the space in the three-dimensional virtual environment. Optionally, the virtual character is a three-dimensional character constructed based on three-dimensional human skeleton technology, and the virtual character achieves different external images by wearing different skins. In some implementations, the virtual character may also be implemented using a 2.5-dimensional or 2-dimensional model, which is not limited in the embodiments of the present application.

[0041] Event Log: Also known as offline message, it is a solution for asynchronous calculation based on stored player interaction data. It is a notification mechanism for weak player interaction in the game, similar to the implementation of email. Asynchronous interaction events are stored in the database in the form of EventLog and notified to the virtual character. After receiving the notification, the virtual character retrieves the EventLog from the database and executes it, mainly to serialize data operations to ensure data consistency.

[0042] Game scene server (Zone Server, Zonesvr): A server used to provide the player's user account login function, lobby service, and the main business logic based on virtual characters, providing services in a clustered manner. After the player logs in to the user account, most of the key data is cached on the Zonesvr. And it is written back to the database regularly. The write-back frequency can be configured to 1 minute to 5 minutes according to actual technical needs. Most of the client's requests are processed directly on the Zonesvr, and the rest are passed to other servers through the Zonesvr for further processing.

[0043] Online Server (OnlineServer, Onlinesvr): A server used for online registration services and message forwarding services. It mainly provides the online status of players and registers the process where online players are located. When it is necessary to forward messages to online players, the messages can be correctly forwarded to the process where the players are located.

[0044] Database (DB): is a warehouse that organizes, stores and manages data according to data structure.

[0045] Database (DB) proxy: It is a request proxy service for the game database (Tcaplus DB). It is used as a proxy for other services to access the game main DB.

[0046] Server-Client Message (CS Message): Also known as a notification message, it is the communication data agreed upon by the game client and the game server for interaction.

[0047] Tips: Weakly visualized pop-up prompts on the client side.

[0048] Figure 1 The structure block diagram of a computer system provided by an exemplary embodiment of the present application is shown. The computer system can be implemented as a system architecture of a login prompt method. The computer system 100 includes: a terminal 120 and a server 140.

[0049] The terminal 120 is installed and runs a client that supports a virtual environment. Exemplarily, the client can be any one of a battle royale shooting game, a virtual reality (VR) application, an augmented reality (AR) program, a three-dimensional map program, a virtual reality game, an augmented reality game, a first-person shooting game (FPS), a third-person shooting game (TPS), a multiplayer online tactical competitive game (MOBA), and a simulation game (SLG).

[0050] The terminal 120 is a terminal used by the user. The user uses the terminal 120 to log in to the user account on the client. During the login period of the user account, events can be processed and data can be loaded. After the user account login is completed, the virtual character in the virtual environment can be controlled, and the control includes but is not limited to: adjusting body posture, crawling, walking, running, riding, jumping, driving, picking up, shooting, attacking, throwing, and building virtual buildings. The user can also use the terminal 120 to release virtual combat skills and control virtual vehicles during combat.

[0051] The embodiment of the present application does not limit the form of the client installed on the terminal 120, including but not limited to App (Application) and applet installed in the terminal 120, and can also be in the form of a web page. The terminal 120 can generally refer to one of multiple terminals, and this embodiment only uses the terminal 120 as an example. The device type of the terminal 120 includes at least one of: a smart phone, a tablet computer, a wearable device, a PC (Personal Computer), a laptop computer, and a desktop computer.

[0052] The terminal 120 is connected to the server 140 via a wireless network or a wired network.

[0053] The server 140 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and cloud servers that provide basic cloud computing services such as big data and artificial intelligence platforms. The server 140 includes at least one server, multiple servers, a cloud computing platform, and a virtualization center. Among them, cloud technology (Cloud Technology) refers to a hosting technology that unifies a series of resources such as hardware, software, and networks in a wide area network or a local area network to achieve data calculation, storage, processing, and sharing. Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model application, which can form a resource pool, which is used on demand and is flexible and convenient. Cloud computing technology will become an important support. The background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture websites, and more portal websites. With the rapid development and application of the Internet industry, every item may have its own identification mark in the future, and all need to be transmitted to the background system for logical processing. Data of different levels will be processed separately. All kinds of industry data require strong system backing support, which can only be achieved through cloud computing.

[0054] Exemplarily, the server 140 includes a processor 144 and a memory 142, and the memory 142 further includes a receiving module 1421, a control module 1422, and a sending module 1423. The receiving module 1421 is used to receive a request sent by a client, such as a login request for a user account, a request to view at least one of the number, position, and attributes of an enemy virtual character, or a request to view at least one of a map and a backpack; the control module 1422 is used to control the rendering of a virtual environment screen; and the sending module 1423 is used to send a response to the client, such as sending to the client the events to be processed and the data to be loaded during the login of the user account, and sending at least one of the number, position, and attribute value of the enemy virtual character. The server 140 is used to provide background services for the client in the terminal 120 that supports the virtual environment.

[0055] Optionally, the server 140 undertakes the main computing work and the terminal 120 undertakes the secondary computing work; or, the server 140 undertakes the secondary computing work and the terminal 120 undertakes the main computing work; or, a distributed computing architecture is used between the server 140 and the terminal 120 for collaborative computing.

[0056] The login prompt method provided in the embodiment of the present application can be performed by a computer device as the execution subject of each step. A computer device refers to an electronic device with data calculation, processing and storage capabilities. Figure 1 Taking the implementation environment of the scheme shown as an example, the login prompt method can be executed by the terminal 120 (such as a client supporting the virtual environment installed and running in the terminal 120 executes the login prompt method), or the login prompt method can be executed by the server 140, or the terminal 120 and the server 140 can interact and cooperate to execute it, and this application does not limit this.

[0057] Those skilled in the art will appreciate that the number of the above-mentioned terminals 120 may be more or less. For example, the above-mentioned terminals 120 may be only one or more. The embodiment of the present application does not limit the number and device type of the terminals 120.

[0058] Take a game that supports a virtual environment as an example. When a player logs in to the game after being offline for a period of time, it is usually necessary to process the interaction data of various interaction events during the offline period during the login period, such as friend gifts, intimate relationship operations, offline chats, etc. After processing these interaction events, the player can log in to the game lobby interface. After logging in to the game lobby interface, some prompts (such as pop-up prompts) may be required for feedback. Usually, only after the player has completely logged in to the game lobby interface can the server send data to the client, and the interaction events processed during the login period cannot send prompt data to the client for feedback.

[0059] In this embodiment, a general solution for offline player login pop-up window prompt based on cache is proposed. The feedback results of various types of services processed by the player during login can be uniformly recorded in the cache structure of the server where the player is located. After the player pulls the data required to be displayed in the user interface (such as friend data), the server will send the cached prompt data to achieve the purpose of offline login pop-up window prompt.

[0060] Figure 2 A schematic diagram of a login prompt method provided by an exemplary embodiment of the present application is shown. Next, taking the example of a user using a terminal 120 to log in to a user account in a client supporting a virtual environment installed and running in the terminal 120, the login prompt method of this embodiment is generally described. Among them, the user logs in to a user account on the terminal 120, and the user account is the first user account. Other users can log in to user accounts on the terminals they hold, and the user account is the second user account.

[0061] like Figure 2 As shown in schematic diagram 121 in , when the first user account is in an online state, the first user account initiates a first offline interaction event to a second user account that is currently in an offline state, and the event type of the first offline interaction event is: applying to establish an intimate relationship.

[0062] like Figure 2 As shown in the schematic diagram 122 in , the first user account performs an offline operation and is in an offline state. During the time period when the first user account is in an offline state, the second user account is in an online state and processes the first offline interaction event initiated by the first user account, and agrees to establish an intimate relationship with the first user account, that is, the second user account initiates a second offline interaction event to the first user account that is currently in an offline state, and the event type of the second offline interaction event is: agree to establish an intimate relationship.

[0063] like Figure 2 As shown in the schematic diagram 123 in , the first user account is offline for a period of time and then logs in again to the first user account. During the login period, the server 140 needs to process the second offline interaction event and update the intimate relationship data with the second user account. After updating the intimate relationship data, the server 140 needs to send a prompt message to the client so that a pop-up window prompt for establishing an intimate relationship is displayed on the client. At this time, if the first user account is still in the login period, the server 140 will cache this prompt message record, and after the first user account completes the login, this prompt message will be sent to the client. At this time, when the first user account enters the game lobby interface, a prompt to establish an intimate relationship with the second user account will pop up as expected.

[0064] Figure 3A flowchart of a login prompt method provided by an exemplary embodiment of the present application is shown, in which the method is applied to Figure 1 The server 140 is illustrated as an example, and the method includes:

[0065] Step 220: When the client requests to log in to the user account, obtain offline interaction events of the user account; offline interaction events are events that occur during a time period when the user account is offline.

[0066] The client refers to a client of an application program that supports a virtual environment and is installed and run on a terminal. A user can log in to a user account on the client. Optionally, the client may also be a client that provides an interactive function, which enables the user account logged in on it to interact with other user accounts logged in on other clients. The two or more clients that implement the interaction may be clients of the same type, or clients of different types that enable data intercommunication.

[0067] Offline interaction events are events that occur during the period when the user account is offline. Offline interaction events are related to the user account and require the user account to participate in or be aware of them.

[0068] For example, taking the interaction between two user accounts, user account 1 and user account 2, as an example, an offline interaction event may be an interaction event that user account 2 actively initiates to user account 1 during the period when user account 1 is offline. For example, actively giving intimacy props to user account 1. Or, an offline interaction event may also be an interaction processing result event corresponding to the interaction actively initiated by user account 2 to user account 1 during the period when user account 1 is offline. For example, user account 2 processes a friend request initiated by user account 1. The friend request is initiated by user account 1 during the period when user account 2 is offline.

[0069] For example, taking the case where the client is a game client that supports a virtual environment, the offline interaction events that occur during the time period when the user account is offline may be at least one of the following: system push, intimacy application, agreement or refusal to establish an intimacy, obtaining trophies, settlement data at the end of a game match or liking a player or sending a gift to a player, score announcement, friend team formation or application or data update, prohibition of team formation, battle schedule update, and hero selection.

[0070] Optionally, when the client requests to log in to a user account, the server obtains offline interaction events of the user account. Exemplarily, offline interaction events are stored in the database in the form of offline messages (EventLog), and the command word of the offline message is used to characterize the event type of the offline interaction event. When the client requests to log in to a user account, the server obtains the EventLog of the user account from the database and executes it.

[0071] Step 240: Process the offline interaction event to obtain offline interaction data of the offline interaction event.

[0072] Offline interaction data refers to interaction data after offline interaction events have been processed.

[0073] Optionally, processing the offline interaction event includes loading data corresponding to the offline interaction event, or updating historical interaction data corresponding to the offline interaction event.

[0074] For example: if the event type of an offline interaction event is a friend request, and the user account that sent the request is a new friend with whom no friendship has been established, then the user account does not save any historical data of the friend, and the data corresponding to the offline interaction event needs to be loaded from scratch. If the event type of an offline interaction event is to give an intimacy item to a friend with whom an intimate relationship has been established, then the user account has saved the historical intimacy data with the friend, and the historical interaction data of the offline interaction event is updated.

[0075] Step 260, based on the offline interaction data of the event to be prompted, generate prompt data of the event to be prompted; the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client.

[0076] The events to be prompted refer to the events in the offline interactive events that need to be prompted on the client. There can be multiple types of events to be prompted. Offline interactive events include events to be prompted and events that do not need to be prompted.

[0077] Optionally, for different user accounts, the event type of the event to be prompted may be exactly the same, that is, no matter which user account is logged in on the client, the event type of the event to be prompted corresponding to the user account is the same.

[0078] Optionally, the user account can also customize the event type of the event to be prompted. For example: there is a first correspondence between the event type of the event to be prompted and the user account, and the event type of the event to be prompted can be bound to the user account identifier. Or, there is a second correspondence between the event type of the event to be prompted and the terminal held by the user, and the event type of the event to be prompted can be bound to the terminal identifier, and the first correspondence is the same as or different from the second correspondence.

[0079] For example: a user has user account 1 and user account 2. The user sets a prompt for offline interaction events of event type 1, event type 2, and event type 3 when the client logs in to user account 1; the user sets a prompt for offline interaction events of event type 3 and event type 5 when the client logs in to user account 2. The user has user account 1 and holds terminal 1 and terminal 2. The user sets a prompt for offline interaction events of event type 5 and event type 6 when the client of terminal 1 logs in to user account 1; the user sets a prompt for offline interaction events of event type 3 and event type 4 when the client of terminal 2 logs in to user account 1.

[0080] The prompt data is data used for prompting the client. Generally, the server sends the prompt data in the form of a notification message, which is used for the client to perform a visual pop-up window prompt. The prompt data in this embodiment can also be called a prompt message.

[0081] For example, the prompt data corresponding to the to-be-prompted events of different event types are different, and the prompt data corresponding to the to-be-prompted events of the same event type but with different user accounts for interaction are different. The server generates the prompt data for the to-be-prompted event based on the offline interaction data of the to-be-prompted event, so as to subsequently send the prompt data to the client in the form of a notification message.

[0082] Step 280: When the user account is in the login state, cache the prompt data of the event to be prompted; and when the user account is in the login completion state, send the cached prompt data to the client.

[0083] In this embodiment, the time period from the time the user account requests login until the login is completed is called the login period. The state corresponding to the user account being in the login period is the user account being logged in state. The state corresponding to the user account completing the login, i.e. entering the game lobby interface, is the user account being logged in state.

[0084] In order to avoid display anomalies that may occur when the client receives a communication message sent by the server during the user account login, the communication message between the server and the client will be filtered out, and once the prompt data of the client prompt type is lost, the user account cannot provide corresponding feedback to the player after the login is completed. Therefore, in this embodiment, when the server sends the prompt data, it will judge the current state of the user account to determine whether the prompt data is cached or sent.

[0085] Specifically, the server obtains the current status of the user account, caches the prompt data of the pending prompt event when the user account is in the login state, and then sends the cached prompt data to the client when the user account is in the login completion state.

[0086] In summary, the method provided in the embodiment of the present application is that when the client requests to log in to the user account, the server obtains the offline interaction events of the user account; processes the offline interaction events to obtain the offline interaction data of the offline interaction events; generates the prompt data of the event to be prompted based on the offline interaction data of the event to be prompted; when the user account is in the login state, the prompt data of the event to be prompted is cached; and when the user account is in the login completion state, the cached prompt data is sent to the client. In the above scheme, when the user account is offline and logs in to the client again, the server can successfully send the prompt data corresponding to the event to be prompted processed by the user account during the login period to the client, so that the prompt can be performed normally on the client after the user account login is completed, and the user's gaming experience is also guaranteed.

[0087] The following embodiments illustrate the method of generating prompt data for the event to be prompted.

[0088] Figure 4 A flowchart of a login prompt method provided by an exemplary embodiment of the present application is shown. Since the prompts required for the prompt events of different event types are different on the client, the prompt data sent by the server to the client are also different. A general method is set in this embodiment.

[0089] Specifically, step 260 can be implemented as the following steps 340 and 360:

[0090] Step 340: Obtain a cache filling function corresponding to the event to be prompted.

[0091] In this embodiment, the cache filling function is a function used to generate prompt data for the event to be prompted. The event type of the event to be prompted corresponds to the cache filling function one by one. That is, different event types of events to be prompted correspond to different cache filling functions, and different cache filling functions correspond to different data contents that can be obtained.

[0092] Step 360: Call the cache filling function to generate prompt data for the event to be prompted based on the offline interaction data of the event to be prompted.

[0093] Exemplarily, the server calls the cache filling function to generate prompt data for the event to be prompted based on the offline interaction data of the event to be prompted.

[0094] As an example, taking the corresponding relationship table shown in Table 1 below as an example, different event types of events to be prompted and their corresponding cache filling functions and prompt data are illustrated:

[0095] Table 1 Correspondence table

[0096]

[0097] In this embodiment, the prompts required for the events to be prompted of different event types are different on the client side, and therefore correspond to different cache filling functions. By obtaining the cache filling function of the event to be prompted and calling the cache filling function, the prompt data of the event to be prompted can be generated. For the events to be prompted of different event types, the prompt data corresponding to them can be quickly generated, which can improve the data processing efficiency, and can also meet the needs of customized prompts for the events to be prompted of different event types, and facilitate business expansion.

[0098] Please continue reading Figure 4 , the above step 340 may be optionally replaced by the following steps 342 and 344:

[0099] Step 342: Search the cache manager for a handle corresponding to the event type of the event to be prompted.

[0100] For example, there are many kinds of prompts that can be performed in the client, but not all prompts need to be triggered during the login period when the user account is offline and then logs in again. Therefore, for the prompt data of the pending prompt event that needs to be prompted in this embodiment, a cache manager (g_stCsTipsCacheManage) is used to manage it. The prompt data that needs to be cached during the login period can be pre-registered in the cache manager.

[0101] Specifically, the cache manager is used to manage the registration information corresponding to the event to be prompted. A handle refers to a tuple pre-registered in the cache manager. The handle is used to store the registration information. The registration information stored in each handle includes the event type of the event to be prompted and the cache filling function corresponding to the event type. The event type of the event to be prompted corresponds to the handle one-to-one. That is, the event type, prompt data, handle, and cache filling function of the event to be prompted correspond one-to-one.

[0102] Step 344, obtaining the cache filling function corresponding to the event to be prompted from the handle.

[0103] Exemplarily, after finding the handle corresponding to the event type of the event to be prompted, the cache filling function corresponding to the event to be prompted can be obtained from the handle.

[0104] In this embodiment, by setting up a global cache manager, it is convenient to uniformly manage the prompt events and their registration information, which can enable the server to quickly determine which offline interactive events need to be prompted and obtain the required cache filling function, which is conducive to improving data processing efficiency.

[0105] Please continue reading Figure 4 , the above step 360 can be specifically implemented as the following steps 362:

[0106] Step 362, calling the cache filling function, filling the offline interaction data of the event to be prompted into the data structure according to the data structure of the prompt data, and generating the prompt data of the event to be prompted;

[0107] Among them, the data structure includes a type field and a content field. The type field is used to represent the event type of the event to be prompted, and the content field is used to represent the data content of the offline interactive data required to be used when prompting the event to be prompted; the data content of the offline interactive data required to be used when prompting the event to be prompted is different for different event types.

[0108] In this embodiment, the prompt data will be sent to the client in the form of a notification message. For the notification message that needs to be prompted, a general CS protocol (CS_CMD_NOTIFY_EVENT_TIPS) is defined. The reply data (NOTIFYEVENTTIPSDATA) of the CS protocol includes two fields, namely the type field (Type) and the content field (Sel).

[0109] The type field is used to characterize the event type of the event to be prompted, and is used by the client to identify the data type of the prompt data. The data type corresponds to the event type one-to-one, that is, the type field can also be used to characterize the data type of the prompt data. The client makes different prompts based on different data types. The content field is a general data structure, and the content field can support corresponding data structures based on different type fields. The content field is used to characterize the data content of the offline interactive data required to prompt the event to be prompted; the data content of the offline interactive data required to prompt the event to be prompted of different event types is different. Based on the type field and its corresponding content field, the client can obtain some specific data content under the event type and make corresponding prompts.

[0110] For example, if the event type is to increase intimacy, the corresponding prompt data is "You and xxx have increased intimacy by n points", and the data content of offline interaction data included in the prompt data (or required to be used) includes the following two types: the other player's information and the increased intimacy value. If the event type is to establish an intimate relationship, the corresponding prompt data is "You have established an intimate relationship of type y with xxx, and the relationship level is n", and the data content of offline interaction data included in the prompt data includes the following four types: the other player's information, the established intimate relationship type, the intimate relationship level, and the time of establishing the intimate relationship.

[0111] Exemplarily, the server calls the cache filling function of the event to be prompted, fills the offline interaction data of the event to be prompted into the data structure according to the above data structure of the prompt data, and generates the prompt data of the event to be prompted.

[0112] The above-mentioned embodiment can improve the efficiency of generating prompt data and meet the technical needs of generating different prompt data for events to be prompted of different event types by setting a common data structure for prompt data. It is also convenient to subsequently cache different prompt data corresponding to events to be prompted of different event types in the same cache data list, which is convenient for management and use, and improves the availability and scalability of the system.

[0113] In some embodiments, only the events to be prompted need to generate corresponding prompt data, and no prompt data is required for the events that do not need to be prompted, which can improve the processing speed of the server and save the space occupied by the cache. Therefore, before step 340, it also includes determining the events to be prompted that need to be prompted in the offline interactive events, so that only the prompt data corresponding to the events to be prompted is generated later.

[0114] Please continue reading Figure 4 The method may further optionally include the following steps 322 and 324:

[0115] Step 322: Based on the event type of each offline interaction event, search the cache manager for a handle corresponding to the event type of each offline interaction event.

[0116] The event type of the event to be prompted corresponds to the handle one by one. In the case where the event type of the offline interaction event can find the corresponding handle, the offline interaction event can be determined as the event to be prompted.

[0117] Optionally, based on the event type of each offline interaction event, the server searches the cache manager for a handle corresponding to the event type of each offline interaction event.

[0118] Step 324: determine the offline interaction event corresponding to the event type with the existing handle as the event to be prompted.

[0119] Exemplarily, the server determines the offline interaction event corresponding to the event type with the handle as the event to be prompted, and then generates corresponding prompt data according to the cache filling function in the handle.

[0120] In this embodiment, whether an offline interaction event is an event to be prompted is determined by whether a handle exists, so that the event to be prompted can be quickly determined from multiple offline interaction events, and only the event to be prompted needs to be processed subsequently, saving server resources.

[0121] Figure 5 The flowchart of a login prompt method provided by an exemplary embodiment of the present application is shown. In step 280, when the user account is in the login state, caching the prompt data of the event to be prompted can be implemented as the following steps 420:

[0122] Step 420, calling the cache filling function of the event to be prompted, and caching the prompt data of the event to be prompted in the cache data list according to the list structure of the cache data list;

[0123] Among them, the cache filling function is also used to cache prompt data; the cache data list is a list pre-set in the server for caching prompt data; the list structure includes a sequence number field and a data field, the sequence number field is used to indicate the arrangement position of the prompt data in the cache data list, and the data field is used to store the prompt data.

[0124] Optionally, in this embodiment, a cache data list (EventTipsDataList) is pre-set in the server, and the cache data list is a data set of the reply data (NOTIFYEVENTTIPSDATA). That is, the cache data list is a list pre-set in the server for caching prompt data. The cache data list can be set in the memory or disk of the server. The cache filling function stores the prompt data that needs to be cached in the cache data list (EventTipsDataList). When sending data, the cache data is obtained by traversing the cache data list (EventTipsDataList), and the work of sending the cache data to the client is completed by obtaining its corresponding data sending processing function.

[0125] Exemplarily, the list structure of the cache data list includes a sequence number field and a data field, wherein the sequence number field is used to indicate the arrangement position of the prompt data in the cache data list, and the data field is used to store the prompt data. The sequence number field can also be used to represent the amount of data, and the amount of data actually required to be pushed by the current user account can be recorded by the number of sequence numbers (Num) contained in the sequence number field.

[0126] In this embodiment, the prompt data of the to-be-prompted events of different event types are cached in the cache data list, thereby realizing temporary storage of the prompt data. At the same time, this method of multiple types sharing the same cache data list also facilitates data management and distribution, improves the availability and scalability of the system, and can meet the prompt requirements of various businesses.

[0127] For example, after the user account login is completed, the cached prompt data in the cache data table (EventTipsDataList) needs to be sent to the client. A common practice is that the client will throw an event after the user account login is completed. In this event, the server will send the cached prompt data to the client one by one. However, when the client displays the prompt data, such as the pop-up prompts in the game intimacy system, it is often necessary to display the relevant information of the player and his friends corresponding to the user account. Therefore, it may happen that when the player account login is completed and the server sends the cached prompt data, this part of the friend data that needs to be displayed has not been sent to the client in full, resulting in the client being unable to display the prompt correctly or not displaying it. Please continue to refer to Figure 5 In step 280 of this embodiment, when the user account is in the login completion state, sending the cached prompt data to the client can be implemented as the following steps 440 and 460:

[0128] Step 440, receiving a business data request sent by the client, and sending business data corresponding to the business data request to the client; business data refers to data that needs to be displayed in the user interface of the client when the user account is in a login completion state.

[0129] After the user account is logged in, the client will actively pull the business data list and obtain the corresponding business data, which refers to the data that needs to be displayed in the client's user interface when the user account is in the login completion state. Before the client completes obtaining the business data, the server still retains the cached prompt data.

[0130] Exemplarily, the server receives a service data request sent by a client, and sends service data corresponding to the service data request to the client.

[0131] Step 460: When the service data is sent and the user account is in a login completion state, the cached prompt data is sent to the client.

[0132] Exemplarily, when the server determines that the service data has been sent and the user account is in a login completion state, the server sends the cached prompt data to the client.

[0133] Wherein, step 460 specifically includes the following steps 462 and 464:

[0134] Step 462, when the business data is sent and the user account is in a login completion state, obtain the data sending function corresponding to the prompt data.

[0135] The data sending function is a function used to send the prompt data. Since different event types of events to be prompted correspond to different prompt data, they also correspond to different data sending functions.

[0136] Exemplarily, the data sending function corresponding to the event to be prompted has been pre-registered in the cache manager. Similar to the cache filling function, the data sending function is also stored in the handle. The corresponding handle can be found through the event type of the event to be prompted corresponding to the prompt data, and the corresponding data sending function can be obtained. Specifically, when the business data is sent and the user account is in the login completion state, the handle corresponding to the event type of the event to be prompted corresponding to the prompt data is obtained from the cache manager; the data sending function corresponding to the prompt data is obtained from the handle; wherein, the handle in the cache manager also stores the data sending function corresponding to the event type of the event to be prompted.

[0137] Step 464, calling the data sending function to send the cached prompt data to the client;

[0138] The data sending function is a function used to send prompt data.

[0139] Exemplarily, the server calls a data sending function to send cached prompt data to the client.

[0140] In the above embodiment, after the client obtains the business data that needs to be displayed on the user interface, the cached prompt data is sent down, which can avoid the situation where the client cannot display the prompt correctly or does not display it, thereby ensuring the accuracy of the prompt display.

[0141] In some embodiments, all the prompt data are sent by traversing the data cache list (EventTipsDataList). Exemplarily, after step 464, steps 465 and 466 are also included:

[0142] Step 465: After the prompt data is sent, the prompt data is removed from the data cache list.

[0143] Exemplarily, after a piece of prompt data is sent, the server removes the prompt data from the cache data list so as to continue traversing the next piece of prompt data.

[0144] Step 466, continue to traverse the next prompt data in the data cache list until all prompt data in the data cache list are traversed.

[0145] Exemplarily, the server continues to traverse the next prompt data in the data cache list until all the prompt data in the data cache list are traversed. After all the prompt data in the data cache list are traversed, the sending of all the prompt data is completed.

[0146] In this embodiment, by traversing the data cache list, it is possible to ensure that each data in the cache data list is traversed, thereby ensuring the accuracy of prompt data delivery.

[0147] Exemplarily, the processing of offline interaction events is described below for different specific types of offline interaction events. Optionally, offline interaction events include at least one of prop interaction events and interaction application events, and prop interaction events refer to offline interaction events that do not require indicating the results of the interaction. For example: User account 1 sends an intimacy prop to user account 2, then for the server of user account 1 and the server of user account 2, both directly update the historical intimacy values ​​between the player of user account 1 and the player of user account 2. An interaction application event refers to an offline interaction event that requires indicating the result of the interaction, and the interaction result includes one of agreeing to the interaction and rejecting the interaction. For example: User account 1 sends an application to establish an intimate relationship to user account 2, then for the server of user account 1, it needs to know whether user account 2 agrees or refuses to establish an intimate relationship. If it agrees to establish an intimate relationship, the server of user account 1 will update the intimacy data accordingly, and the updated intimacy data includes the intimacy with user account 2.

[0148] For example, Figure 6 The flowchart of the login prompt method provided by an exemplary embodiment of the present application is shown. The above step 260 may include at least one of step 520 and step 540:

[0149] Step 520, when the offline interaction event is a prop interaction event, the historical interaction data of the prop interaction event is updated to obtain the offline interaction data of the prop interaction event.

[0150] Exemplarily, when the offline interaction event is a prop interaction event, the server updates the historical interaction data corresponding to the prop interaction event to obtain the offline interaction data of the prop interaction event. The historical interaction data includes the historical data between the user accounts that interacted corresponding to the prop interaction event.

[0151] Step 540: When the offline interaction event is an interaction application event, the interaction application event is processed based on the interaction result data corresponding to the interaction application event to obtain offline interaction data of the interaction application event.

[0152] Exemplarily, when the offline interaction event is an interaction application event, the server processes the interaction application event based on the interaction result data corresponding to the interaction application event to obtain offline interaction data of the interaction application event. The above-mentioned processing of the interaction application event includes loading or updating the data of the user account that agrees to the interaction corresponding to the interaction application event.

[0153] Specifically, when the offline interaction event is an interaction application event, the server obtains interaction result data corresponding to the interaction application event, updates historical interaction data of the interaction application event based on the interaction result data, and obtains offline interaction data of the interaction application event.

[0154] The interaction result data is data used to indicate the interaction result, and the interaction result includes one of agreeing to the interaction and rejecting the interaction. Optionally, in the case of agreeing to the interaction, based on the interaction result data, the historical interaction data of the interaction application event is updated to obtain the offline interaction data of the interaction application event. In the case of rejecting the interaction, there is no need to update the historical interaction data of the interaction application event.

[0155] Through the above embodiments, it is possible to process offline interaction events based on their specific types, thereby making the processing of offline interaction events more targeted and improving the accuracy of processing results.

[0156] Next, taking a game client supporting a virtual environment as an example, the login prompt method provided in this embodiment is described in conjunction with a schematic diagram.

[0157] Many scenes in the game can be interacted in the form of EventLog. Specifically, the player initiates a request to the game server where he is through his user account, and the game server writes the request to the Eventlog table corresponding to the user account of the target interactive player through the DB proxy. After the write is successful, an EvenLog update notification will be initiated to the target interactive player through the online server. If the online server finds the interactive player, it will forward this notification message (CS message) to the game server where the target interactive player is located, otherwise the notification message will be discarded. If the target interactive player is online, the corresponding notification message will be received, and the player data will be processed and updated by querying the EventLog table. If the target interactive player is offline, when the target interactive player logs in again, the data of all Eventlog tables will be pulled for processing and the player data will be updated. Only after all EventLogs are processed can the player data be updated to the latest state. In order to ensure the validity of the player data received by the client, the notification message sent by the server to the client will be blocked before the user account of the target interactive player completes the login. However, when processing some EventLogs, it is usually hoped that the client can give the player some prompts for feedback after processing these EventLogs, and the feedback needs to be sent to the client in the form of CS messages. It is possible that the CS message fed back during the login of the user account is blocked and sent because the player data has not been updated, resulting in the client being unable to prompt normally after the user account is logged in.

[0158] In this embodiment, a common cache block is created for each player's user account during login. If the offline interaction events processed by the player during login require prompts from the client, the server can record these messages in the cache block. After the login is completed, the server will traverse the data in the cache block and send them to the client one by one. After receiving the message, the client can display the corresponding prompt feedback for the player, realizing the pop-up window prompt for the player's offline login.

[0159] In this embodiment, an asynchronous calculation scheme for player interaction data based on storing Eventlog tables is used, and is applied to multiple business systems such as friend operations, intimacy systems, gifting props, and email sending and receiving. These operations usually provide real-time feedback to the client when the player completes the interaction. When both players are online, the client can provide real-time feedback. For a player who is offline, the player can also receive corresponding feedback results when logging in again after being offline.

[0160] Figure 7 A schematic diagram of a login prompt method provided by an exemplary embodiment of the present application is shown. Figure 7(1)(3)(5)(7) in the figure are schematic diagrams of the client where player A logs in. Figure 7 (2)(4)(6) in the figure are schematic diagrams of the client logged in by player B. Taking the application in the intimacy system as an example, the interactive process of establishing an intimacy relationship is implemented using Eventlog. The specific interactive process is:

[0161] like Figure 7 As shown in (1), when player A (710) is online, player A can send a request 700 to player B (720) to establish an intimate relationship. Figure 7 As shown in (2), player B is offline. Figure 7 As shown in (3), after player A sends a request to player B to establish an intimate relationship, he exits the game and remains offline. Figure 7 As shown in (4), after player B logs in to the client, he will receive a new request in the friend list. After opening the request, a request 730 for applying for a relationship will pop up. After player B clicks to agree, Figure 7 As shown in (6), a pop-up window 740 will pop up immediately indicating that player B and player A have successfully established a close relationship. Figure 7 As shown in (5), player A is still offline at this time. At the same time, player B will send an Eventlog message to player A to inform player A that he has agreed to the request to establish a relationship. Player A needs to process this Eventlog and establish the corresponding relationship the next time he goes online. Player A logs in to the client again, and during the login period, he will process the Eventlog sent by player B to agree to establish an intimate relationship. Update the player's intimate relationship data and add player B as his confidant. After updating the data, the server needs to send a prompt message to player A's client, which will be used for the client to pop up a window prompt to establish an intimate relationship. At this time, player A is still in the login period, so the server will record the prompt message in the player's general prompt cache block, and send the prompt message after player A is fully logged in. As shown in the figure below: Figure 7 As shown in (7), when player A enters the game lobby, a prompt 750 for establishing a close relationship will pop up as expected.

[0162] Figure 8 A schematic diagram of a login prompt method provided by an exemplary embodiment of the present application is shown. Figure 8 (1)(3)(5) in the figure are schematic diagrams of the client where player A logs in. Figure 8 (2)(4)(6) in the figure are schematic diagrams of the client logged in by player B. Taking the intimacy system as an example, in the game, players can send intimacy items such as "little thoughts" to each other, and these intimacy items can increase the intimacy between the two parties. The specific interaction process is:

[0163] like Figure 8 As shown in (1), player A opens the gift page 760 and selects a specified number of small gifts to give to a specified friend. Here, the gift is given to an offline friend, that is, player B. At this time, Figure 8 As shown in (2), player B is in offline state 770. Figure 8 As shown in (3), after giving away the "little thought" item, player A will receive a prompt that the gift was successful and the corresponding intimacy is increased. The prompt 780 is displayed as "The gift of the little thought was successful, and the relationship with player B has become closer, intimacy +1". Figure 8 As shown in (4), player B is still offline 770, and player A will send an event log to player B to increase intimacy. Player B needs to handle this event the next time he goes online. Player B logs in to the client, as shown in Figure 8 As shown in (5), a prompt 782 indicating that player B is online is displayed on player A's client. During the login period of player B's client, the Evenlog event sent by player A is processed to update the intimacy data between himself and the other party. Figure 8 As shown in (6), after player B logs in, a prompt 790 for increasing intimacy with player A pops up in the game public lobby, and the prompt is displayed as "Intimacy with player A +1". Although the event type and data content corresponding to this prompt are different from those of the prompt for establishing an intimacy in the above embodiment, this part of the prompt data can still be uniformly recorded in the player's general prompt cache block, and uniformly issued after player B completes login, so as to be prompted on player B's client.

[0164] Players can still receive various interactions during offline periods, and these interactions are stored in the player's database in the form of offline message Eventlog. Each time a player logs into the game, he needs to obtain all offline message Eventlog data during the login period from the database for corresponding processing. Only after processing Eventlog can the authenticity and validity of the player's data be guaranteed, and the player can log in to the lobby to interact with various games. During the processing of Eventlog data, notification messages from the server and the client will be filtered out. Otherwise, there may be display abnormalities after the client receives the notification message. Once many client prompt messages are lost, the player will not be able to provide corresponding feedback after logging into the game. This embodiment proposes a general solution for pop-up window prompts for offline player logins based on caching. Fig. 9 A schematic diagram of a login prompt method provided by an exemplary embodiment of the present application is shown, and the implementation process of the method is briefly described as follows:

[0165] 1. The process starts;

[0166] 2. The player logs in to the client through the user account;

[0167] 3. The server processes the eventlog during the offline period; then proceed to step 4;

[0168] 4. The server sends a message, specifically, the prompt data is sent in the form of a notification message; execute 5;

[0169] 5. The server determines whether the user account is in the login state (Logining); if yes (in the login state), continue to execute 6; if no (not in the login state, in the login completion state), continue to execute 12;

[0170] 6. The server filters the message, that is, filters out the notification message of the prompt data; and proceeds to step 7;

[0171] 7. The server caches the message, i.e., caches the notification message of the prompt data; and continues to execute 8;

[0172] 8. When the user account login is completed, the client will send a friend data request and actively pull friend data; the server will continue to execute 9;

[0173] 9. The server sends friend data to the client; continue to execute 10;

[0174] 10. After all the friend data is sent, the server determines whether the user account is in the login state (Logining); if not (not in the login state, in the login completion state), continue to execute 11;

[0175] 11. The server traverses the messages cached during execution 7;

[0176] 12. The server sends a pop-up message to the client, which is a notification message of prompt data;

[0177] 13. The client pops up a window to remind you;

[0178] 14. The process ends.

[0179] Since the offline message Eventlog shields the upper-layer business from performing different processing on whether the interacting player is online, regardless of whether the player is online or not, the upper-layer business has a unified processing logic through Eventlog, as if the player is always online. Therefore, after processing the Eventlog event, if a corresponding pop-up window prompt is required to the client, a notification message will be sent directly to the client. The framework layer of message processing filters the notification messages in the logged-in state, resulting in the inability to convey the notification messages. Based on this, this embodiment adds a cache data for the storage and distribution of prompt data, and the specific implementation is as follows:

[0180] Cache design

[0181] Different types of services require different prompts on the client, and the prompt data that the server needs to send to the client is also different. There may be multiple identical prompts for the same type of service. This embodiment sets a common cache data list for storing prompt data during the offline login period.

[0182] For notification messages that require pop-up window prompts, this embodiment defines a general CS protocol (CS_CMD_NOTIFY_EVENT_TIPS). Its reply packet data (NOTIFYEVENTTIPSDATA) contains two fields: Type and Sel. In an example, the reply packet data structure is as follows:

[0183] {

[0184] Char chType;

[0185] NOTIFYEVENTTIPSDATASEL stSel;

[0186] }

[0187] Type is used by the client to identify the data type of the prompt. The client will make different pop-up prompts according to different data types. The data type corresponds to the event type one by one. Sel is a universal (Union) data structure, which can support corresponding data structures according to different Types. The client can obtain specific data under the type according to Type and Sel and make corresponding pop-up prompts.

[0188] The structure of NOTIFYEVENTTIPSDATASEL is listed below:

[0189] {

[0190] SYSNOTICE stSysNotice; / *EVENT_TIPS_TYPE_INTERACT EVENT SYS_NOTICE, system notification message* /

[0191] NOTIFYITIMATETIPS setItimateTips; / *EVENT TIPS_TYPE_INTERACT EVENTFRIEND ITIMATE,Ver.178 Close friends TIPS push* /

[0192] NOTIFYCUPDATATIPS stCupDataTips; / *EVENT TIPS_TYPE INTERACT EVENT_CUPDATA,Ver.329 The client gets the trophy push* /

[0193] ROOML IKEPERSON stRoomLikePerson; / *EVENT TIPS TYPE_ROOM LIKE PERSON,Ver.357 Like the player during settlement* /

[0194] ROOMPRESENT stRoomPresent; / *EVENT TIPS TYPE_ROOM PRESENT ANARD BOX,Ver.531 Give gifts to other players during settlement* /

[0195] GUILDLEVELUP stGuildLevelUp; / *EVENT TIPS_TYPE_GUILD LEVEL UP,Ver.607 guild upgrade* /

[0196] PLAYAGAINMEMSTATUSCHANGE stPlayAgainMemStatusChange; / *EVENT TIPS_TYPEPLAYAGAIN MEMBER STATUS CHANGE,Ver.1813 The status of the player who plays again changes* /

[0197] MATCHTEAMROOMNTFTIPS stMatchTeamRoomNtfTips; / *EVENT TIPS TYPE TEAMROOM_NOTIFY TIPS,Ver.1078Friends team up tips* /

[0198] RESE TGRADETIPS stResetGradeTips; / *EVENT_TIPS_TYPE_RESET GRADE,Ver.1200 Racer reset tips* /

[0199] GUILDMSGNTFTIPS stGuildMsgNtfTips; / *EVENT TIPS_TYPE.GUILD MSG,Ver.1703 Guild dynamic tips* /

[0200] GUILDINFONTFTIPS stGuildInfoNtfTips; / *EVENT TIPS_TYPE_GUILD INFO,Ver.1746 Guild member information and member list change notification* /

[0201] char chGuildApply; / *EVENT TIPS_TYPE GUILD APPLY,Ver.1822 Guild application tips* /

[0202] PLAYAGAINLEADERGRADE INFO stPlayagainLeaderGradeInfo; / *EVENT TIPS_TYPE_PLAYAGAIN NTF_LEADER GRADE,Ver.2006 Play again and synchronize the captain's rank information* /

[0203] uint64 t ullSimpleInfoChangeUin; / *EVENT TIPS_TYPE FRIEND SIMPLEINFOCHANGE,Ver.2023Notify friends of simpleinfo changes* /

[0204] GUTILDNARPUBLISHSCORETIPS stGuildWarPublishScore; / *EVENT TIPS_TYPEGUILDMAR PUBLISH SCORE,Ver.2147 Guild War Score Announcement* /

[0205] UNDERAGEFORBIDMATCHTEAM stUnderAgeForbidTips; / *EVENT TIPS TYPELUNDERAGE FORBID MATCH TEAM,Ver.2316Underage prohibited to play / prohibited to form a team notification* /

[0206] VOICEMEMBERIDUPDATE stVoiceMemberIdUpdate; / *EVENT TIPS TYPE_VOICEMEMBERID UPDATE,Ver.2761 Client voice ID update - settlement interface* /

[0207] PLAYERNEGATIVETIPS stPlayerNegativeTips; / *EVENT TIPS TYPE_PLAYERNEGATIVE,Ver.2763 Player Negative Behavior* /

[0208] GUILDWARSCHEDULE stGui ldNarSchedule; / *EVENT TIPS TYPE GVG SCHEDULE_UPDATE,Ver.3056 Guild war schedule update* /

[0209] REMARDBUFFGRADEUPRANGE stRewardBuffGradeUpRange; / *EVENT TIPS TYPE_RENIARD BUFF.GRADE_UP.RANGW,Ver.3081 upper and lower limits of reward rank ID* /

[0210] EVENTTIPOPENCHAMPIONQUEUE stOpenChampionQueue; / *EVENT TIPS_TYPE OPENCHAMPION QUEQUE,Ver.3220 Canyon of the Top ticket activation* /

[0211] EVENTTIPCHAMPIONQUEUEGRADEWILLFADE stChampionQueueGradeWillFade; / *EVENT TIPS.TYPE_CHAMPION QUEUE GRADE_WILL_FADE,Ver.3220 The rank of the Canyon of Heroes will fade soon* /

[0212] EVENTTIPSELHERO stSelHero; / *EVENT TIPS_TYPE_SEL HERO,Ver.3329 hero selection notification* /

[0213] EVENTTIPMELEEPROGRAM stMeleeProgram; / *EVENT_TIPS_TYPE MELEE PROGRAM,Ver.3329 Big Fight Program Tips* /

[0214] EVENTSOCIALUPDATE stSocialUpdate; / *EVENT TIPS_TYPE SOCIAL LUPDATE,Ver.3355 Personal information social data update* /

[0215] FRIENDCOMMDATA stFriendCommData; / *EVENT TIPS TYPE_FRIEND COMM DATAUPDATE,Ver.3694Friends common data update* /

[0216] EVENTTIPSTEAMSOULCARD stEventTips TeamSoulCard; / *EVENT_TIPS_TYPE_TEAM SOUL_CARD,Ver.4072Team Soul Card operation notification* /

[0217] }

[0218] It can be seen that this embodiment supports client pop-up prompts of various event types. A global g_stCsTipsCacheManage is used to manage pop-up type data that needs to be triggered during the offline login period. The prompt data that needs to be cached during the login period can be registered in g_stCsTipsCacheManage. The registered content mainly includes the data type of the prompt data (one-to-one corresponding to the event type), one-to-one corresponding cache filling function and data sending function.

[0219] This embodiment pre-applies a cache data in the memory data of the server for storing the cache data list (EventTipsDataList). The cache data list is a data set of NOTIFYEVENTTIPSDATA, and Num records the amount of data that the current player actually needs to push. The cache filling function will store the prompt data that needs to be cached in the EventTipsDataList, and when sending prompt data, the cached prompt data is obtained by traversing the EventTipsDataList list, and the corresponding data sending function is obtained through its data type to complete the work of sending data to the client.

[0220] Message Cache

[0221] Since Eventlog data is not only processed when the player logs in offline, but also various interactive events during the player's online state will be implemented through Eventlog. There is no need for special operations to process Eventlog, that is, there is no need to consider the situation where the player is online or offline separately. Instead, it is judged when the message is sent: Under normal circumstances, when Zonesvr sends CS messages to the client, it will judge the player's current login status. If the player is currently logged in, the message will be filtered. Then, the data to be sent is processed by calling the report_send_msg_on_logining function. The processing logic of Zonesvr sending messages is as follows:

[0222] if(pstPlayer->chLogining)

[0223] {

[0224] report_send_msg.on_logining(pstPlayer->ul1Uin,pstPkg);

[0225] return 0; / / Login in, filter messages to be sent

[0226] }

[0227] In report_send_msg_on_logining, call handle_role_cache_msg_on_logining to cache the player's key messages (that is, notification messages of prompt data that need to be popped up), and send them to the client when the player is in the login completion state. The specific implementation is: get the data type corresponding to the prompt data from the sent pstPkg data, and get the corresponding handle from g_stCsTipsCacheManage according to the data type. If the handle does not exist, it means that no prompt is needed, and the notification message of the prompt data does not need to be cached; if the handle exists, the cache filling function is obtained through the handle, and the notification message of the prompt data is stored in EventTipsDataList. The implementation logic is as follows:

[0228] void report_send_msg_on_logining(uint64_t ul11RoleID,LPCSMSGS pstPkg)

[0229] {

[0230] CHECK_PARAM_NORET(pstPkg); / / Cache the key message and send it to the client after the player logs in successfully

[0231] handle_role_cache_msg_on_logining(u1lRoleID,pstPkg);

[0232] }

[0233] ·Message delivery

[0234] After the player completes the login, the prompt data cached in EventTipsDataList needs to be sent to the client. Usually, after the player completes the login, the client will throw an event, in which the cached prompt data will be sent to the client one by one. There may be problems at this time, such as the pop-up prompts in the intimacy system, which often also contain relevant information about the player and his friends. After the player completes the login, the client will request the friend data for the display of the friend information. Therefore, when the server sends the cached prompt data, the player's friend data may not be returned to the client, resulting in the client being unable to correctly display the pop-up information or not displaying it.

[0235] This embodiment also optimizes the logic of message sending: after the player completes the login, the client will actively pull the friend list to obtain the friend data. Before the friend data is obtained, the server still retains the cached prompt data. After the server sends the full amount of friend data to the client, it can throw an event: report_role_get_friend_list_finish, and put all the processing logic required after the friend list is obtained in this event, so as to push the cached prompt data to the client. The processing logic here can be expressed as follows:

[0236] void report_role_get__friend list_finish(LPROLE pstRole)

[0237] {

[0238] CHECK_PARAM NORET(pstRole); / / Send cached tips data to the client;

[0239] send_cache__msg__to_client(pstRole);

[0240] clog_debug("report_role__get_friend_list_finish");

[0241] }

[0242] The specific implementation of the data sending function send_cache_msg_to_client is:

[0243] In some embodiments, a configuration switch is also provided for turning on and off the login prompt function. When the configuration switch is in the off state, the cached prompt data will not be sent. The server obtains a cache data list (EventTipsDataList) based on the user account of the player requesting to log in. If the amount of data in the cache data list is 0, the data sending function will end directly. Before sending the data, it is also necessary to judge the status of the player's user account. When the user account is in the login state, the data is not sent to achieve data protection. After completing the above inspection work, traverse each prompt data in the cache data list, and obtain the corresponding handle from the cache manager (g_stCsTipsCacheManage) according to the data type (or event type) corresponding to the prompt data. If the handle does not exist, the data is removed and the next prompt data is processed. If the handle exists, the data sending function is obtained from the handle to complete the data sending. After the data sending is completed, the data sent this time is removed from the cache data list. After traversing all the data in the cache data list, the sending of all offline login pop-up window data is completed. Fig.10 A schematic diagram of a login prompt method provided by an exemplary embodiment of the present application is shown, and the data sending processing logic is as follows:

[0244] 1. The process starts;

[0245] 2. Check whether the configuration switch is on. If yes, go to step 3; otherwise, go to step 13.

[0246] 3. Determine whether the data amount Num in the cache data list is greater than 0; if so, execute 4; otherwise, execute 13;

[0247] 4. Set i=0; continue with step 5;

[0248] 5. Determine whether i is less than Num; if yes, execute 6, otherwise execute 13;

[0249] 6. Get the hint data of the i-th cache from the cache line data list; continue to execute 7;

[0250] 7. Get the handle of the data; continue to execute 8;

[0251] 8. Determine whether the handle exists; if yes, continue to execute 8, otherwise execute 11;

[0252] 9. If the handle exists, the data sending function is obtained from the handle to send the pop-up message (i.e. the prompt data cached in 6); continue to execute 10 and 11 at the same time;

[0253] 10. Send the pop-up message to the client;

[0254] 11. Remove the pop-up message sent this time from the cache data list; continue to execute 12;

[0255] 12. Set i=i+1; continue with step 5;

[0256] 13. The process ends.

[0257] In other embodiments, for the sending of cached prompt data, it is also possible to choose to consume the cached data by timer timing processing. That is, the cached data list is traversed every two seconds, and the cached prompt data in the cached data list is sent. Accordingly, whether it is offline login or online chat pop-up information, pop-up prompts can be effectively performed in the client. It is understandable that due to the characteristics of timer timing consumption, if the timer time interval is too long, the pop-up message prompt may not be timely. If the timer time interval is too short, it will cause greater pressure on the server, thereby affecting the performance and stability of the server to a certain extent. Therefore, when using a timer to send data, it is necessary to set the time interval of the timer according to actual technical needs.

[0258] In summary, the method provided in the embodiment of the present application filters and caches the prompt data sent by notification messages when the user account is in the login state (during login), and uses the cache data list pre-set in the server to temporarily store the prompt data that needs to be prompted. After the client obtains the business data that needs to be displayed (such as: friend data in the friend list), the cached prompt data is sent to the client one by one, which can realize that when the user account login is completed, the prompt is successfully displayed on the client, and the prompt feedback of the offline interactive events processed during the login period is realized, ensuring the user's gaming experience. At the same time, the use of multiple types of sharing the same cache data list for unified data management and data distribution greatly improves the availability and scalability of the system, can meet the customized prompt requirements of various businesses, and facilitate the continued expansion of the game business.

[0259] For example, Fig.11 The structural block diagram of a login prompt device provided by an exemplary embodiment of the present application is shown. The login prompt device 800 includes:

[0260] The acquisition module 810 is used to acquire offline interaction events of the user account when the client requests to log in to the user account; the offline interaction events are events that occur during a time period when the user account is in an offline state.

[0261] The processing module 820 is used to process the offline interaction event to obtain offline interaction data of the offline interaction event.

[0262] The generating module 830 is used to generate prompting data of the event to be prompted based on the offline interaction data of the event to be prompted; the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client.

[0263] The sending module 840 is used to cache the prompt data of the event to be prompted when the user account is in the login state; and to send the cached prompt data to the client when the user account is in the login completion state.

[0264] In some embodiments, the generating module 830 is used to:

[0265] Obtaining a cache filling function corresponding to the event to be prompted;

[0266] Calling the cache filling function to generate the prompt data of the event to be prompted based on the offline interaction data of the event to be prompted;

[0267] There is a one-to-one correspondence between the event type of the event to be prompted and the cache filling function, and the cache filling function is a function used to generate the prompt data of the event to be prompted.

[0268] In some embodiments, the generating module 830 is used to:

[0269] Searching for a handle corresponding to the event type of the event to be prompted from the cache manager;

[0270] Obtain the cache filling function corresponding to the event to be prompted from the handle;

[0271] Among them, the cache manager is used to manage the registration information corresponding to the event to be prompted, the handle refers to a tuple pre-registered in the cache manager, and the handle is used to store the registration information. The registration information stored in each handle includes the event type of the event to be prompted and the cache filling function corresponding to the event type. The event type of the event to be prompted corresponds to the handle one-to-one.

[0272] In some embodiments, the generating module 830 is used to:

[0273] Based on the event type of each offline interaction event, searching the cache manager for a handle corresponding to the event type of each offline interaction event;

[0274] An offline interaction event corresponding to the event type having the handle is determined as the event to be prompted.

[0275] In some embodiments, the generating module 830 is used to:

[0276] Calling the cache filling function, filling the offline interaction data of the event to be prompted into the data structure according to the data structure of the prompt data, and generating the prompt data of the event to be prompted;

[0277] Among them, the data structure includes a type field and a content field, the type field is used to represent the event type of the event to be prompted, and the content field is used to represent the data content of the offline interactive data required to be used when prompting the event to be prompted; the data content of the offline interactive data required to be used when prompting the event to be prompted of different event types is different.

[0278] In some embodiments, the sending module 840 is used to:

[0279] Calling the cache filling function of the event to be prompted, and caching the prompt data of the event to be prompted in the cache data list according to the list structure of the cache data list;

[0280] Among them, the cache filling function is also a function used to cache the prompt data; the cache data list is a list pre-set in the server for caching the prompt data; the list structure includes a sequence number field and a data field, the sequence number field is used to indicate the arrangement position of the prompt data in the cache data list, and the data field is used to store the prompt data.

[0281] In some embodiments, the sending module 840 is used to:

[0282] receiving a service data request sent by the client, and sending service data corresponding to the service data request to the client; the service data refers to data that needs to be displayed in the user interface of the client when the user account is in a login completion state;

[0283] When the service data is sent completely and the user account is in a login completion state, the cached prompt data is sent to the client.

[0284] In some embodiments, the sending module 840 is used to:

[0285] When the service data is sent and the user account is in a login completion state, obtaining a data sending function corresponding to the prompt data;

[0286] Calling the data sending function to send the cached prompt data to the client;

[0287] The data sending function is a function used to send the prompt data.

[0288] In some embodiments, the sending module 840 is used to:

[0289] When the service data is sent and the user account is in a login completion state, obtaining a handle corresponding to the event type of the event to be prompted corresponding to the prompt data from the cache manager;

[0290] Obtaining the data sending function corresponding to the prompt data from the handle;

[0291] The handle in the cache manager also stores a data sending function corresponding to the event type of the event to be prompted.

[0292] In some embodiments, the sending module 840 is further used to:

[0293] After the prompt data is sent, removing the prompt data from the data cache list;

[0294] Continue to traverse the next prompt data in the data cache list until all the prompt data in the data cache list are traversed.

[0295] In some embodiments, the offline interaction event includes at least one of a prop interaction event and an interaction application event. The prop interaction event refers to an offline interaction event that does not require indication of an interaction result. The interaction application event refers to an offline interaction event that requires indication of an interaction result. The interaction result includes one of agreeing to the interaction and rejecting the interaction.

[0296] In some embodiments, the processing module 820 is used to:

[0297] In the case where the offline interaction event is the prop interaction event, updating the historical interaction data of the prop interaction event to obtain the offline interaction data of the prop interaction event;

[0298] In the case where the offline interaction event is the interaction application event, the interaction application event is processed based on the interaction result data corresponding to the interaction application event to obtain offline interaction data of the interaction application event.

[0299] In some embodiments, the processing module 820 is used to:

[0300] In a case where the offline interaction event is the interaction application event, acquiring interaction result data corresponding to the interaction application event;

[0301] Based on the interaction result data, the historical interaction data of the interaction application event is updated to obtain the offline interaction data of the interaction application event.

[0302] It should be noted that the specific limitations in the embodiments of the one or more login prompt devices provided above can refer to the limitations of the login prompt method above, which will not be repeated here. Each module of the above device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor of the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0303] An embodiment of the present application also provides a computer device, which includes: a processor and a memory, wherein a computer program is stored in the memory; and the processor is used to execute the computer program in the memory to implement the login prompt method provided by the above-mentioned method embodiments.

[0304] Fig.12 1000 is a block diagram of a computer device provided by an exemplary embodiment of the present application. Optionally, the computer device is a server. The server 1000 includes: a processor 1001 and a memory 1002.

[0305] The processor 1001 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1001 may be implemented in at least one hardware form of digital signal processing (DSP), field programmable gate array (FPGA), and programmable logic array (PLA). The processor 1001 may also include a main processor and a coprocessor. The main processor is a processor for processing data in an awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 1001 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1001 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0306] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1002 is used to store at least one instruction, and the at least one instruction is used to be executed by the processor 1001 to implement the login prompt method provided in the method embodiment of the present application.

[0307] In some embodiments, the server 1000 may also optionally include: an input interface 1003 and an output interface 1004. The processor 1001, the memory 1002, the input interface 1003, and the output interface 1004 may be connected via a bus or a signal line. Each peripheral device may be connected to the input interface 1003 and the output interface 1004 via a bus, a signal line, or a circuit board. The input interface 1003 and the output interface 1004 may be used to connect at least one peripheral device related to input / output (I / O) to the processor 1001 and the memory 1002. In some embodiments, the processor 1001, the memory 1002, the input interface 1003, and the output interface 1004 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1001, the memory 1002, the input interface 1003, and the output interface 1004 may be implemented on a separate chip or circuit board, which is not limited in the embodiments of the present application.

[0308] Those skilled in the art will understand that Fig.12 The structure shown in the figure does not constitute a limitation on the computer device, and may include more or less components than shown in the figure, or combine some components, or adopt a different component arrangement.

[0309] The present application provides a chip, which includes a programmable logic circuit and / or program instructions. When the chip runs on a computer device, it is used to implement the login prompt method provided by the above method embodiment.

[0310] The present application provides a computer-readable storage medium, which stores a computer program. The computer program is loaded and executed by a processor to implement the login prompt method provided by the above method embodiment.

[0311] The present application provides a computer program product or a computer program, wherein the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the processor of the computer device loads and executes to implement the login prompt method provided in the above method embodiment.

[0312] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0313] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned computer-readable storage medium may be a read-only memory, a disk or an optical disk, etc.

[0314] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented with hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein the communication media include any media that facilitates the transmission of a computer program from one place to another. The storage medium can be any available medium that a general or special-purpose computer can access.

[0315] The above description is only an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A login prompt method, characterized in that: The method is applied to a server, and the method comprises: When a client requests to log in to a user account, obtaining offline interaction events of the user account; the offline interaction events are events that occur during a time period when the user account is offline; Processing the offline interaction event to obtain offline interaction data of the offline interaction event; Based on the offline interaction data of the event to be prompted, generating prompt data of the event to be prompted; the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client; When the user account is in a login state, the prompt data of the event to be prompted is cached; and when the user account is in a login completion state, the cached prompt data is sent to the client.

2. The method according to claim 1, characterized in that The generating of prompting data of the event to be prompted based on the offline interaction data of the event to be prompted includes: Obtaining a cache filling function corresponding to the event to be prompted; Calling the cache filling function to generate the prompt data of the event to be prompted based on the offline interaction data of the event to be prompted; There is a one-to-one correspondence between the event type of the event to be prompted and the cache filling function, and the cache filling function is a function used to generate the prompt data of the event to be prompted.

3. The method according to claim 2, characterized in that The step of obtaining a cache filling function corresponding to the event to be prompted includes: Searching for a handle corresponding to the event type of the event to be prompted from the cache manager; Obtain the cache filling function corresponding to the event to be prompted from the handle; Among them, the cache manager is used to manage the registration information corresponding to the event to be prompted, the handle refers to a tuple pre-registered in the cache manager, and the handle is used to store the registration information. The registration information stored in each handle includes the event type of the event to be prompted and the cache filling function corresponding to the event type. The event type of the event to be prompted corresponds to the handle one-to-one.

4. The method according to claim 3, characterized in that The method further comprises: Based on the event type of each offline interaction event, searching the cache manager for a handle corresponding to the event type of each offline interaction event; An offline interaction event corresponding to the event type having the handle is determined as the event to be prompted.

5. The method according to claim 2, characterized in that: The calling of the cache filling function to generate the prompt data of the event to be prompted based on the offline interaction data of the event to be prompted includes: Calling the cache filling function, filling the offline interaction data of the event to be prompted into the data structure according to the data structure of the prompt data, and generating the prompt data of the event to be prompted; Among them, the data structure includes a type field and a content field, the type field is used to represent the event type of the event to be prompted, and the content field is used to represent the data content of the offline interactive data required to be used when prompting the event to be prompted; the data content of the offline interactive data required to be used when prompting the event to be prompted of different event types is different.

6. The method according to any one of claims 1 to 5, characterized in that: When the user account is in a logged-in state, caching the prompt data of the event to be prompted includes: Calling the cache filling function of the event to be prompted, and caching the prompt data of the event to be prompted in the cache data list according to the list structure of the cache data list; Among them, the cache filling function is also a function used to cache the prompt data; the cache data list is a list pre-set in the server for caching the prompt data; the list structure includes a sequence number field and a data field, the sequence number field is used to indicate the arrangement position of the prompt data in the cache data list, and the data field is used to store the prompt data.

7. The method according to any one of claims 1 to 6, characterized in that: When the user account is in a login completion state, sending the cached prompt data to the client includes: receiving a service data request sent by the client, and sending service data corresponding to the service data request to the client; the service data refers to data that needs to be displayed in the user interface of the client when the user account is in a login completion state; When the service data is sent completely and the user account is in a login completion state, the cached prompt data is sent to the client.

8. The method according to claim 7, characterized in that When the sending of the service data is completed and the user account is in a login completion state, sending the cached prompt data to the client includes: When the service data is sent and the user account is in a login completion state, obtaining a data sending function corresponding to the prompt data; Calling the data sending function to send the cached prompt data to the client; The data sending function is a function used to send the prompt data.

9. The method according to claim 8, characterized in that When the sending of the service data is completed and the user account is in a login completion state, obtaining a data sending function corresponding to the prompt data includes: When the service data is sent and the user account is in a login completion state, obtaining a handle corresponding to the event type of the event to be prompted corresponding to the prompt data from the cache manager; Obtaining the data sending function corresponding to the prompt data from the handle; The handle in the cache manager also stores a data sending function corresponding to the event type of the event to be prompted.

10. The method according to any one of claims 7 to 9, characterized in that: The method further comprises: After the prompt data is sent, removing the prompt data from the data cache list; Continue to traverse the next prompt data in the data cache list until all the prompt data in the data cache list are traversed.

11. The method according to any one of claims 1 to 10, characterized in that: The offline interaction event includes at least one of a prop interaction event and an interaction application event, wherein the prop interaction event refers to an offline interaction event that does not need to indicate an interaction result, and the interaction application event refers to an offline interaction event that needs to indicate an interaction result, wherein the interaction result includes one of agreeing to the interaction and rejecting the interaction; The processing of the offline interaction event to obtain offline interaction data of the offline interaction event includes: In the case where the offline interaction event is the prop interaction event, updating the historical interaction data of the prop interaction event to obtain the offline interaction data of the prop interaction event; In the case where the offline interaction event is the interaction application event, based on the interaction result data corresponding to the interaction application event, the interaction application event is processed to obtain offline interaction data of the interaction application event; In the case where the offline interaction event is the interaction application event, the interaction application event is processed based on the interaction result data corresponding to the interaction application event to obtain offline interaction data of the interaction application event, including: In a case where the offline interaction event is the interaction application event, acquiring interaction result data corresponding to the interaction application event; Based on the interaction result data, the historical interaction data of the interaction application event is updated to obtain the offline interaction data of the interaction application event.

12. A login prompt device, characterized in that: The device comprises: An acquisition module, configured to acquire offline interaction events of a user account when a client requests to log in to the user account; the offline interaction events are events that occur during a time period when the user account is offline; A processing module, used to process the offline interaction event to obtain offline interaction data of the offline interaction event; A generating module, configured to generate prompting data of the event to be prompted based on the offline interaction data of the event to be prompted; the event to be prompted refers to an event in the offline interaction event that needs to be prompted on the client; The sending module is used to cache the prompt data of the event to be prompted when the user account is in a login state; and to send the cached prompt data to the client when the user account is in a login completion state.

13. A computer device, characterized in that: The computer device comprises: a processor and a memory, wherein the memory stores a computer program, and the computer program is loaded and executed by the processor to implement the login prompt method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is loaded and executed by a processor to implement the login prompt method according to any one of claims 1 to 11.

15. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. The processor obtains the computer instructions from the computer-readable storage medium, so that the processor loads and executes to implement the login prompt method as described in any one of claims 1 to 11.

Images