Game access method and device, equipment and medium thereof

Abstract

The application relates to a game access method and device, equipment and medium, the method comprising: in response to a game access event triggered by a player user, mapping request parameters corresponding to the event into standardized protocol data according to preset standard rules, the standardized protocol data comprising an abstract identifier for hiding real identity information of the player user in the game access event; converting the standardized protocol data into an access request adapted to a heterogeneous protocol corresponding to a game provider of a game to which the game access event belongs; sending the access request to a game server corresponding to the game provider, driving the game server to execute corresponding game interaction logic based on the abstract identifier in the access request; and receiving response data returned by the game server and restoring the response data into standardized response data according to the standard rules. The application effectively solves the problems of high access cost and privacy leakage risk caused by heterogeneous protocols of multiple game providers.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a game access method, apparatus, device, and medium thereof. Background Technology

[0002] With the rapid development of internet technology, the online gaming industry has experienced explosive growth, with various game providers launching diverse game products to meet the entertainment needs of different user groups. In various application scenarios such as e-commerce platforms and social media platforms, integrating third-party game services has become a common operational method to enhance user stickiness and platform activity.

[0003] However, different game providers typically use their own independent communication protocols and data formats, resulting in significant protocol heterogeneity. Platforms face numerous technical challenges when integrating services from multiple game providers. Current technologies usually require platforms to develop separate adaptation interfaces for each game provider, leading to high integration costs and lengthy development cycles. More importantly, the interface specifications of each game provider often contain sensitive information such as real user identifiers, posing a privacy risk during cross-platform transmission.

[0004] Furthermore, the lack of a unified protocol conversion mechanism in existing technologies means that data interaction between the platform and the game server requires maintaining processing logic for multiple heterogeneous protocols. This not only increases implementation complexity but also makes business expansion and maintenance difficult. When a new game provider is added or an existing provider updates its interface specifications, the entire access layer often needs to be modified, making rapid and flexible expansion difficult. Summary of the Invention

[0005] The primary objective of this application is to solve at least one of the aforementioned problems by providing a game access method, apparatus, device, or medium thereof.

[0006] To achieve the various objectives of this application, the following technical solution is adopted: A game access method provided for one of the purposes of this application includes the following steps: In response to a game access event triggered by a player, the system maps the request parameters corresponding to the event to standardized protocol data according to preset standard rules. The standardized protocol data includes an abstract identifier used to hide the real identity information of the player in the game access event. Based on the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs, the standardized protocol data is converted into an access request adapted to the heterogeneous protocol; The access request is sent to the game server corresponding to the game provider, and the game server is driven to execute the corresponding game interaction logic based on the abstract identifier in the access request. Receive the response data returned by the game server, and parse and restore the response data into standardized response data according to the standard rules.

[0007] A game access device proposed for one of the purposes of this application, comprising: The event response module is configured to respond to game access events triggered by players. According to preset standard rules, the request parameters corresponding to the event are mapped to standardized protocol data. The standardized protocol data includes an abstract identifier used to hide the real identity information of the player in the game access event. The request conversion module is configured to convert the standardized protocol data into an access request adapted to the heterogeneous protocol based on the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs. The request sending module is configured to send the access request to the game server corresponding to the game provider, and drive the game server to execute the corresponding game interaction logic based on the abstract identifier in the access request. The response receiving module is configured to receive response data returned by the game server and parse the response data into standardized response data according to the standard rules.

[0008] In another aspect, a computer device provided for one of the purposes of this application includes a central processing unit and a memory, wherein the central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the game access method described in this application.

[0009] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the game access method, which, when invoked by a computer, executes the steps included in the corresponding method.

[0010] Compared with existing technologies, the advantages of this application are as follows: First, this application achieves efficient and unified access to heterogeneous protocols by introducing standardized protocol data as an intermediate layer abstraction. Specifically, upon receiving a game access event, this application first converts the request parameters into standardized protocol data that is independent of specific game providers, and then performs targeted conversion based on the heterogeneous protocols of different providers. This layered and decoupled architecture design means that when adding a new game provider, only the standard rules need to be extended without modifying the core standardized processing logic, which significantly shortens the access cycle and reduces development investment.

[0011] Secondly, the abstract identifier mechanism effectively solves the problem of user privacy leakage during cross-platform transmission. Specifically, during the standardized protocol data construction phase, the real identifier is encrypted and converted to generate an abstract identifier that is only valid in the context of the game access. When the game server executes the game interaction logic based on the abstract identifier, it can accurately identify the user's identity and restore the session state, but it cannot know the user's real identity, thus forming an effective privacy isolation barrier. This design not only meets data security compliance requirements, but also enhances users' trust in the platform, which is conducive to the long-term healthy development of the business.

[0012] Furthermore, a bidirectional protocol conversion mechanism enables standardized processing throughout the entire game integration process. Original requests from the platform side undergo standardized mapping and heterogeneous protocol conversion before reaching the game server. Heterogeneous responses from the game server are reverse-analyzed and standardized before being returned to the platform side. This end-to-end standardized closed loop ensures that the application platform always faces a unified data format, completely shielding it from the protocol differences of the underlying game providers. When game providers update their interface specifications, the platform's business code can smoothly adapt without any modifications, significantly enhancing scalability and resilience to changes. Attached Figure Description

[0013] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the game access method of this application; Figure 2 This is a schematic block diagram of the game access device of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0014] The game access method of this application can be deployed in a network architecture that provides game service integration for various application platforms to achieve its functionality. In a typical application scenario, this network architecture includes an application platform, a game access server, and multiple game servers. The game access method of this application is deployed and implemented in the game access server. The application platform can be an e-commerce platform, social platform, or content aggregation platform, providing users with a game entry point through its client interface. The game access server is deployed on the platform side, acting as an intermediary layer connecting the application platform and various game providers, undertaking core functions such as protocol conversion, data standardization, and privacy protection. The game servers are deployed separately by different third-party game service providers, each using heterogeneous communication protocols and data formats to interact with the outside world.

[0015] In the network architecture described above, when a user triggers a game access request through the application platform, the request is first sent to the game access server. The game access server converts the request parameters into standardized protocol data based on preset standard rules, encrypting the real user identifier into an abstract identifier during this process to protect privacy. Subsequently, the game access server, according to the heterogeneous protocol of the target game provider, converts the standardized data into an access request adapted to that provider and forwards it to the corresponding game server. The game server executes the game interaction logic based on the abstract identifier and returns response data. The game access server then parses the response data back into a standardized format and returns it to the application platform. This architecture allows the application platform to access multiple heterogeneous game services in a unified manner, without needing to concern itself with underlying protocol differences.

[0016] For ease of understanding, the basic probabilities involved in this application are explained below. Standardized protocol data refers to a general data format defined according to preset standard rules, independent of the specific game provider's protocol specifications, used to achieve unified data representation and processing within the game access server. Abstract identifiers are alternative identifiers obtained by converting real identifiers through encryption rules, used to hide the user's real identity information in cross-platform data transmission, protecting user privacy while ensuring the game server can correctly identify user sessions and execute corresponding logic based on this identifier. Heterogeneous protocols refer to the different communication protocols adopted by different game providers. These differences are reflected in various aspects such as request structure definition, field naming conventions, data encoding methods, and transmission mechanisms. Protocol conversion templates are a set of predefined conversion rules for heterogeneous protocols of a specific game provider, including request structure descriptions, field mapping relationships, and encoding format specifications, used to guide bidirectional conversion between standardized protocol data and heterogeneous protocol data. Metadata cache is used to store game metadata extracted from various game providers and uniformly encapsulated, supporting application platforms to quickly obtain game list information to render interactive interfaces; the business cache library is used to store personalized metadata that is re-encapsulated according to specific business identifiers, avoiding redundant processing and improving response efficiency.

[0017] Based on the aforementioned network architecture and fundamental concepts, the game access method of this application can achieve efficient, secure, and flexible connection between the application platform and multiple heterogeneous game service providers, providing a technical foundation for the development of subsequent specific embodiments.

[0018] Unless otherwise specified, the term "server" as used in this application specifically refers to the game access server.

[0019] Please see Figure 1 The game access method of this application, in its typical embodiment, includes the following steps: Step S3100: Respond to the game access event triggered by the player user, and map the request parameters corresponding to the event to standardized protocol data according to the preset standard rules. The standardized protocol data includes an abstract identifier used to hide the real identity information of the player user in the game access event. In specific application scenarios of game integration, a game integration event is triggered when a player clicks a game icon or triggers a specific game function entry point through the application platform's client interface. The request parameters carried by this event include raw data such as user identity information, session information, target game identifier, and business operation type. Upon receiving this event, its corresponding event type is first identified, such as a user login authentication event, a game launch event, a game data query event, or a virtual item transaction event. Different event types correspond to different business processing logic and data format requirements; therefore, a set of standard rules needs to be maintained to regulate the data processing flow for various events.

[0020] The standard rules exist in a configurable form, containing multiple standardized interface templates. Each template defines complete data field specifications for a specific event type. Taking the user login authentication event as an example, its corresponding standardized interface template explicitly specifies the abstract user identifier field, abstract room identifier field, timestamp field, client version field, and extended parameter fields that this event must include. The structure and type definitions of these fields ensure that regardless of the client from which the original request comes or the format of the data it carries, it can ultimately be converted into unified standardized protocol data.

[0021] During the field mapping process, the real user identifier and the real room identifier serve as identifiers representing the real identity information of player users. The real user identifier is a unique numerical number or string assigned to a user during registration on the application platform. Directly exposing this identifier poses a risk of malicious tracking or correlation analysis during cross-platform transmission. The real room identifier, on the other hand, is internal code within the application platform used to identify specific game rooms or sessions. Directly exposing this identifier would leak the platform's internal business logic structure or session state information. The real identifiers representing the player user's real identity information are converted according to preset encryption rules to generate corresponding abstract user identifiers and abstract room identifiers. The encryption rules can be implemented using symmetric encryption algorithms, such as using advanced encryption standards to encrypt the real identifiers and encode them as strings, with the key negotiated and rotated periodically between the game access server and the specific game provider. Alternatively, a hash mapping method can be used, such as using a salted hash algorithm to map the real user identifier to a fixed-length digest value, ensuring irreversible derivation and different game providers obtaining different abstract identifiers to avoid cross-platform correlation.

[0022] After the identifier conversion is completed, the abstract user identifier, abstract room identifier, and business parameters in the request parameters are encapsulated according to the field structure defined in the standardized interface template. The specific content of the business parameters varies depending on the event type. For example, a game launch event may include parameters such as game mode selection and room number specification, while a virtual item transaction event may include parameters such as item code, quantity, and transaction type. During the encapsulation process, metadata such as protocol version number, data integrity check code, and validity period timestamp are also added to the standardized protocol data to ensure the reliability and timeliness of the data in subsequent transmission and processing. The final standardized protocol data exists in the server's memory in the form of a structured data object, or is serialized into a specific format such as JSON or Protocol Buffers for temporary storage, preparing for subsequent protocol conversion steps.

[0023] Through the above standardized processing flow, heterogeneous raw request parameters were successfully converted into internally unified standardized protocol data. This not only standardized the data format for subsequent processing, but also cut off the direct exposure path of real user identity information through the abstract identification mechanism, laying the foundation for building a secure and scalable multi-game provider access system.

[0024] Step S3200: Based on the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs, convert the standardized protocol data into an access request adapted to the heterogeneous protocol; After generating the standardized protocol data, the next step is to convert this data into a specific format that the target game provider can recognize and process. The core of this process lies in accurately identifying the target game provider and applying the corresponding heterogeneous protocol. The game identifier field included in the standardized protocol data can be used to determine the specific game product to which this access event refers. Each game product is assigned a unique game identifier within the access system, and this identifier has a clear attribution mapping relationship with the service provider offering that game. The game access server maintains a mapping table between game identifiers and provider identifiers; by querying this mapping table, the provider identifier of the target game provider can be determined.

[0025] In one embodiment, after determining the provider identifier, a protocol conversion template corresponding to the heterogeneous protocol of the target game provider is retrieved from a preset protocol adaptation library. The protocol adaptation library is one of the core components of the game access server, centrally storing protocol conversion templates for various access game providers in a configurable or plug-in format. Each protocol conversion template is customized for a specific provider's heterogeneous protocol, defining in detail the request structure specification, field mapping rules, and encoding format requirements of that heterogeneous protocol. The request structure specification describes the overall organization of the request data packet specified by the heterogeneous protocol, including the arrangement order and length limits of each part such as the protocol header area, authentication information area, business payload area, and checksum area; the field mapping rules establish a one-to-one or one-to-many conversion relationship between standardized protocol data fields and heterogeneous protocol fields; the encoding format requirements specify the specific method of data serialization, including but not limited to character encoding set selection such as UTF-8 or GBK, byte order definition such as big-endian or little-endian, data compression algorithm application such as GZIP or custom compression, and transport layer encapsulation format such as HTTP JSON, HTTP FORM, TCP binary stream, or WebSocket frame structure.

[0026] During the actual conversion execution phase, the values ​​of each field in the standardized protocol data are extracted and filled into the corresponding positions in the heterogeneous protocol request structure according to the field mapping rules. For numeric fields, number system conversion or precision adjustment is required; for string fields, length truncation or padding alignment is necessary; and for set fields, expansion into multiple repeating structures or encoding into strings connected by specific delimiters is required. Some heterogeneous protocols also require embedding specific authentication credentials or timestamp signatures in the request structure, necessitating real-time calculation and insertion of these dynamically generated fields according to the game provider's authentication specifications. After field filling, the entire request structure is serialized and encoded according to the encoding format requirements, generating an access request in binary byte stream or text string format. This access request conforms to the target game provider's interface specifications, can be correctly parsed and processed by its game server, and its internal business semantics remain consistent with the original game access event. The abstract identifier is also correctly transmitted during this process to maintain the continuity of the user session.

[0027] The above protocol conversion process shields the heterogeneity of protocols between different game providers, enabling the application platform to initiate game access requests in a unified and standardized manner without needing to concern itself with the specific technical implementation details of the target game provider. This greatly reduces the development and maintenance costs of accessing multiple game providers.

[0028] Step S3300: Send the access request to the game server corresponding to the game provider, and drive the game server to execute the corresponding game interaction logic based on the abstract identifier in the access request; After completing the protocol conversion and generating an access request that conforms to the heterogeneous protocol specifications of the target game provider, a network connection needs to be established with the corresponding game server to complete data delivery. The method of connection establishment depends on the communication protocol stack used by the game provider. Regardless of the underlying transmission mechanism used, the server will perform an integrity check on the access request before sending it, ensuring that metadata such as protocol header identifiers, length fields, and checksums are correct, preventing the game server from failing to parse the data due to corruption.

[0029] After the access request reaches the game server, the server parses the request and extracts the values ​​of each field. Since the access request follows the game provider's heterogeneous protocol, the parsing process proceeds smoothly, and the game server is unaware that the request has undergone upstream standardization and protocol conversion. Among the parsed fields, the abstract user identifier and abstract room identifier are used to identify, associate, and track user session states. When the game server receives an access request containing an abstract identifier, it first checks whether the abstract identifier corresponds to an existing active session. If it exists, it directly reuses the session's context data, including user level, virtual currency balance, and game progress status. If it does not exist, it creates a new session record and stores the abstract identifier associated with the initialized session state. This design allows the game server to accurately identify users and maintain the continuity of game interaction without obtaining the user's real identity, satisfying both business functional requirements and privacy protection goals.

[0030] Based on the restored or newly created session context, the game server executes the game interaction logic specified in the access request. The specific content of the game interaction logic varies depending on the event type of the access request. For example, for a user login authentication event, it verifies the validity of the abstract identifier, loads the user's historical data in the game, initializes the game scene, and returns a login success response; for a game launch event, it allocates game server resources, creates a game room or matches opponents, and pushes initial game status data to the client; for a game data query event, it retrieves the data range requested by the user from the database or cache, such as leaderboard information, item inventory list, task completion progress, etc., and assembles it into query results; for a virtual item transaction event, it executes a complex business verification process, including checking whether the user's balance is sufficient, whether the item inventory is sufficient, and whether the transaction frequency exceeds the limit, etc., and performs atomic operations of currency deduction and item distribution after all verifications pass, and records transaction logs for subsequent auditing. Throughout the entire execution of the game interaction logic, the abstract identifier always serves as the sole basis for user identity throughout each processing stage. All business operations, data storage, and log recording within the game server are based on this abstract identifier, forming a complete closed-loop process.

[0031] Step S3400: Receive the response data returned by the game server, and parse and restore the response data into standardized response data according to the standard rules.

[0032] After the game server completes the execution of the game interaction logic, it returns the processing result to the game access server in a format conforming to its heterogeneous protocol specifications. This return process is conducted through the previously established network connection channel. Upon arrival of the response data, it first undergoes transport layer protocol parsing, such as HTTP response status code checking, TCP stream reassembly, or WebSocket frame decoding, to extract the original payload data. After obtaining the payload of the response data, it needs to be parsed and restored according to the heterogeneous protocol corresponding to the response data. This parsing process is the reverse of the protocol conversion process when sending the access request mentioned above. First, based on the provider identifier associated with the currently processed game access event, the parsing rules corresponding to the heterogeneous protocol are retrieved from the protocol adaptation library. The parsing rules define in detail how to extract the values ​​of each field from the data packet structure of the heterogeneous protocol, and the response data is decomposed layer by layer according to the parsing rules.

[0033] After parsing, the original response data is obtained. This data still uses the heterogeneous protocol field naming and data type definitions of the game provider, including abstract identifier fields, business result data fields, and possible extended information fields. The value of the abstract identifier field in the original response data is consistent with or has a version update relationship with the abstract identifier in the access request sent in the previous steps. The specific content of the business result data field varies depending on the type of game interaction logic. The naming, type, and organization of these data fields completely follow the game provider's private specifications and cannot be directly understood and processed by the application platform. Therefore, in one embodiment, it is necessary to further convert the original response data into standardized response data. This conversion process is based on the standardized interface template corresponding to the current event type in the standard rules, mapping the abstract identifier field in the original response data to the abstract identifier field position defined by the standardized interface template, ensuring that the privacy protection of user identity information continues in the response path. For the business result data, field mapping and data conversion operations are performed to convert the private field names in the heterogeneous protocol into unified field names defined by the standard rules, convert the enumerated values ​​of specific codes into general status codes defined by the standard rules, and flatten or reorganize the data structure customized by the game provider into a hierarchical structure specified by the standard rules.

[0034] As can be seen from the typical embodiments of this application, the technical solution of this application has many advantages, including but not limited to the following aspects: First, this application achieves efficient and unified access to heterogeneous protocols by introducing standardized protocol data as an intermediate layer abstraction. Specifically, upon receiving a game access event, this application first converts the request parameters into standardized protocol data that is independent of specific game providers, and then performs targeted conversion based on the heterogeneous protocols of different providers. This layered and decoupled architecture design means that when adding a new game provider, only the standard rules need to be extended without modifying the core standardized processing logic, which significantly shortens the access cycle and reduces development investment.

[0035] Secondly, the abstract identifier mechanism effectively solves the problem of user privacy leakage during cross-platform transmission. Specifically, during the standardized protocol data construction phase, the real identifier is encrypted and converted to generate an abstract identifier that is only valid in the context of the game access. When the game server executes the game interaction logic based on the abstract identifier, it can accurately identify the user's identity and restore the session state, but it cannot know the user's real identity, thus forming an effective privacy isolation barrier. This design not only meets data security compliance requirements, but also enhances users' trust in the platform, which is conducive to the long-term healthy development of the business.

[0036] Furthermore, a bidirectional protocol conversion mechanism enables standardized processing throughout the entire game integration process. Original requests from the platform side undergo standardized mapping and heterogeneous protocol conversion before reaching the game server. Heterogeneous responses from the game server are reverse-analyzed and standardized before being returned to the platform side. This end-to-end standardized closed loop ensures that the application platform always faces a unified data format, completely shielding it from the protocol differences of the underlying game providers. When game providers update their interface specifications, the platform's business code can smoothly adapt without any modifications, significantly enhancing scalability and resilience to changes.

[0037] Based on any embodiment of the method in this application, in response to a game access event triggered by a player user, the request parameters corresponding to the event are mapped to standardized protocol data according to preset standard rules. The standardized protocol data includes an abstract identifier used to hide the player user's real identity information in the game access event, including: Step S3110: Based on the event type of the game access event, match the corresponding standardized interface template in the standard rules. The standardized interface template defines the abstract identifier field and business parameter field required by the event type. The event types for game access events are used to distinguish different business scenarios and processing logics. Their determination can be based on the operation type identifier carried in the request parameters or on the characteristics of the function entry point triggered by the request. Common event types include, but are not limited to, user authentication events, game session initialization events, game status query events, virtual asset operation events, and in-game social interaction events. Each event type corresponds to different business processing flows and data interaction requirements.

[0038] In one embodiment, standardized interface templates are stored in the rule engine of the game access server in a structured configuration. Each standardized interface template has a unique event type identifier and version number, supporting multiple versions to achieve smooth upgrades. The template internally defines all data field specifications required for that event type, including two main categories: abstract identifier fields and business parameter fields. The abstract identifier field carries encrypted user identity and session information, including at least an abstract user identifier field and an abstract room identifier field. In some scenarios involving multi-device collaboration, an abstract device identifier field may also be included. These fields explicitly specify data types (e.g., fixed-length strings or UUID format), length limits, character set ranges, and whether they can be nullable, ensuring that all data processed by the template has a unified structural characteristic.

[0039] Business parameter fields are defined differently based on the specific business implications of the event type. For example, in a user authentication event, the standardized interface template defines business parameter fields including authentication method identifiers such as password authentication, SMS verification code authentication, or third-party OAuth authentication, credential data, client timestamp, device fingerprint information, and geolocation information. In a game session initialization event, business parameter fields include the target game identifier, the desired game mode such as single-player mode, multiplayer mode, or spectator mode, graphics preference settings, and network environment self-detection results. In a virtual asset operation event, business parameter fields include the operation type such as balance query, recharge, consumption, or transfer, asset type identifier, operation quantity, counterparty identifier, and risk control verification token. Each business parameter field also defines its data type, value range, default value, validation rules, and dependencies with other fields in the template.

[0040] During execution, the original request for the game access event is first parsed, extracting key information that explicitly or implicitly indicates the event type. For requests using the standard HTTP protocol, the event type can be indicated by the URL pattern of the request path, the type identifier in the query parameters, or the opcode field in the request body. For requests triggered asynchronously via message queues, the event type can be carried by the message subject name or the type attribute in the message header. An event type identification rule base is maintained, supporting judgment based on a combination of multiple features. For example, when the request path matches a specific regular expression and contains specific query parameters, it is determined to be a game status query event. After identifying the event type, a standardized interface template corresponding to that event type is retrieved from the standard rule base. If multiple versions are found, a unique template is determined based on the version identifier carried in the request or by using the default latest version strategy. If no matching template is found, an exception handling process is triggered, returning an unsupported event type error.

[0041] Step S3120: Convert the real user identifier and / or real room identifier in the real identity information of the player user contained in the request parameters into abstract user identifier and / or abstract room identifier according to the preset encryption rules. Player identity information may include a real user identifier and / or a real room identifier. The real user identifier is a globally unique identifier assigned to a user when registering an account on the application platform. It can be an auto-incrementing numeric number, a randomly generated string, or a combination of identifiers with specific encoding rules. This identifier remains consistent across all business systems within the platform and is used to associate core data such as user account information, transaction records, and behavior logs. The real room identifier is a unique tracking identifier assigned by the application platform to each specific game session or room instance. It can be a timestamp, a random number, or a combination of specific algorithms, used to uniquely mark an ongoing or established game match, team, or room at the platform level. The direct exposure of these identifiers to cross-platform transmission poses a significant risk. Malicious third parties can intercept communication traffic to obtain the real user identifier, thereby enabling user profiling, cross-platform identity association, or targeted phishing attacks. Therefore, it is necessary to generate abstract identifiers through encryption to achieve privacy protection.

[0042] The preset encryption rules support multiple encryption algorithms and strategies to adapt to different security level requirements and performance constraints. In one embodiment, encryption is performed using a symmetric encryption algorithm. A shared key is pre-negotiated with a specific game provider. The real identifier is encrypted using an Advanced Encryption Standard (AES) algorithm, and the encrypted binary data is encoded into Base64 or hexadecimal strings as an abstract identifier. Key management employs a periodic rotation mechanism to maintain the mapping relationship between key version identifiers and validity periods. During encryption, key version information is embedded in the abstract identifier to ensure correct decryption by the recipient. If decryption fails, a key synchronization or alarm process is triggered. Symmetric encryption is computationally efficient and suitable for high-concurrency scenarios, but it requires high security in key distribution and storage, necessitating the use of a hardware security module or key management system.

[0043] In another embodiment, encryption is performed using an asymmetric encryption algorithm to generate a public-private key pair. The public key is securely distributed to the game provider, while the private key is strictly stored in the server-side hardware security module. During conversion, the public key is used to encrypt the real identifier to generate an abstract identifier. If the game server needs to parse the real identifier, it must send the abstract identifier back to the game access server, which then decrypts it using the private key and returns it. The advantage of asymmetric encryption is that even if the public key is leaked, the security of the real identifier will not be compromised, and the game server does not need to maintain the decryption key, simplifying the security responsibility boundary. However, it has a large computational overhead and is usually only used in scenarios with extremely high security levels or in combination with symmetric encryption for hybrid encryption.

[0044] In another embodiment, encryption is performed using a hash mapping algorithm, which is suitable for scenarios where reverse parsing of the real identifier is not required. A salted hash algorithm, such as HMAC based on a cryptographic hash function, is used to perform a one-way transformation of the real identifier, generating a fixed-length digest value as the abstract identifier. The salt value is randomly generated by the server and stored in association with the user identifier or session identifier, ensuring that the same real identifier generates different abstract identifiers on different game providers or at different times, preventing rainbow table attacks and cross-platform identifier association. The hash mapping method is highly computationally efficient and does not require key distribution, but it is irreversible. The game server cannot independently parse the real identifier; all operations requiring real identity information must be relayed through the game access server, increasing coupling.

[0045] This step can be encrypted using any of the encryption rules mentioned above. After conversion, the abstract user identifier and abstract room identifier, along with key version identifier, encryption algorithm identifier, and other metadata, are encapsulated for subsequent standardized protocol data assembly. Simultaneously, a mapping relationship between the real identifier and the abstract identifier is established in a local or distributed cache, with a reasonable expiration time set to match the session validity period, supporting the rapid restoration of the real identifier based on the abstract identifier during subsequent response processing. Through this encryption conversion process, effective desensitization of user identity information is achieved without altering the game's business logic, constructing a privacy protection barrier between the platform and third-party game services.

[0046] Step S3130: Encapsulate the abstract user identifier, the abstract room identifier, and the business parameters contained in the request parameters according to the field structure defined in the standardized interface template to generate the standardized protocol data.

[0047] After completing the conversion of abstract identifiers and matching of standardized interface templates, the data encapsulation stage begins. This stage integrates the various components processed separately into standardized protocol data with a complete structure and uniform format. This encapsulation process strictly follows the field structure specifications defined by the loaded standardized interface templates, ensuring that the generated standardized protocol data fully meets expectations in terms of field order, data type, and encoding format, thus laying the foundation for subsequent protocol conversion and cross-system transmission.

[0048] Through the above embodiments, by converting real user identifiers and real room identifiers into abstract identifiers, the data transmitted across platforms no longer contains any sensitive information that can directly identify user identities or track specific game sessions. This effectively blocks attack paths by malicious third parties that intercept communication traffic to build user profiles or perform behavioral correlation analysis. At the same time, the introduction of abstract identifiers does not disrupt the normal operation of the game service; the game server can still accurately identify user identities and locate specific game rooms based on the abstract identifiers, achieving a balance between security and functionality.

[0049] Based on any embodiment of the method in this application, according to the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs, the standardized protocol data is converted into an access request adapted to the heterogeneous protocol, including: Step S3210: Based on the provider identifier in the request parameters, determine the protocol conversion template corresponding to the heterogeneous protocol of the target game provider from the preset protocol adaptation library. The protocol conversion template defines the request structure, field mapping rules and encoding format of the heterogeneous protocol. The protocol adaptation library centrally stores the protocol conversion-related configurations and code logic for all game providers connected to the application platform. Designed in a modular and pluggable manner, the library supports dynamic loading and hot updates, ensuring that new game providers joining or existing provider protocol changes take effect without requiring a server restart. The physical storage format of the protocol adaptation library can be a configuration file directory in a local file system, a collection of records in a database, a key-value store in a distributed configuration center, or a plugin module in a code repository; the specific implementation depends on the application platform's deployment architecture and operational requirements.

[0050] The protocol adaptation library contains multiple protocol conversion templates. Each template is pre-defined for a specific heterogeneous protocol version of a particular game provider. In one embodiment, the protocol conversion template has a unique identifier, which can be composed of a provider identifier, a protocol type identifier, and a version number, ensuring accurate matching to the protocol specification currently used by the target game provider. The protocol template contains three core definition parts: request structure definition, field mapping rule definition, and encoding format definition. The request structure definition describes the overall organization and hierarchical relationship of the request data packets specified by the heterogeneous protocol; the field mapping rule definition establishes the bidirectional conversion relationship between standardized protocol data fields and heterogeneous protocol fields; and the encoding format definition specifies the specific technical specifications for data serialization and deserialization.

[0051] During this step, based on the provider identifier carried in the request parameters, a list of all protocol conversion templates supported by the target game provider is retrieved from the protocol adaptation library. If the target game provider only supports a single protocol version, a unique template is directly determined; if it supports multiple protocol versions, the applicable template version is determined based on the protocol version identifier, request characteristics, or negotiation mechanism carried in the standardized protocol data.

[0052] Step S3230: According to the field mapping rules, fill the field values ​​in the standardized protocol data into the corresponding positions of the request structure, and encapsulate them according to the encoding format to generate the access request.

[0053] After loading the corresponding protocol conversion template, the standardized protocol data is converted into an external format that the target game provider can recognize and process. Specifically, for each field mapping entry, the value of the source field is extracted from the standardized protocol data, and the result is written to the specified position in the request structure. After replacing all field values, a complete but unserialized request data object is obtained. This object is then converted into a byte stream or text string that can be transmitted over the network through encoding and encapsulation operations. The final generated access request can be represented as a complete network message.

[0054] Through the above embodiments, by introducing a protocol adaptation library, the heterogeneous protocol differences of different game providers are encapsulated in a configurable and hot-updateable template, enabling the platform to handle diverse external protocols in a unified and standardized manner. This embodiment significantly reduces the access cost of adding new game providers, supports new protocol specifications without modifying the core code, and shortens the business launch cycle.

[0055] Based on any embodiment of the method in this application, it further includes: Step S4100: Respond to the metadata retrieval request and convert the metadata identifier corresponding to the request into a standard identifier based on the identifier mapping rule; Before displaying the game entry list or game details page on the application platform's client interface, game metadata needs to be acquired in advance to support interface rendering. This acquisition process is triggered by a metadata acquisition request initiated by the client. Metadata acquisition requests can occur when a user enters the game center page, refreshes the game list, or switches game category tags. The metadata identifier carried in the request specifies the range of data to be acquired. It can be a global identifier indicating that all game metadata is to be acquired, or a category identifier such as card games, role-playing games, or casual puzzle games to indicate that game metadata of a specific category is to be acquired, or a precise game product identifier to indicate that detailed metadata of a single game is to be acquired.

[0056] The identifier mapping rules define the transformation logic from client-side metadata identifiers to server-side standard identifiers. Each mapping rule consists of two parts: a pattern matching condition and a transformation action. The pattern matching condition defines the metadata identifier characteristics to which the rule applies, including prefix matching, regular expression matching, exact matching, or range matching. The transformation action defines how to generate the standard identifier, which can be done through table lookup transformations, such as associating hash values ​​with predefined standard identifiers via a mapping table.

[0057] This standard identifier is used to convert heterogeneous game metadata identifiers from different game providers into a unified internal identifier for subsequent retrieval of the corresponding metadata.

[0058] Step S4200: Obtain the corresponding standard metadata from the preset distributed cache according to the standard identifier. The standard metadata is obtained by encapsulating common data fields extracted from multiple heterogeneous game metadata through a unified metadata structure. Distributed caching can be implemented using a memory-based distributed storage system to support high-concurrency, low-latency read access. Cache nodes are distributed across multiple server instances, and a consistent hashing algorithm can be used to map metadata identifiers to specific nodes, achieving load balancing and horizontal scaling. The standard metadata in the distributed cache is a standardized data set pre-encapsulated according to a unified metadata structure. This ensures that regardless of the game provider or proprietary format of the original metadata, the final encapsulated standard metadata has completely consistent structural characteristics. This step directly retrieves the corresponding standard metadata from the pre-defined distributed cache based on the standard identifier obtained in the preceding steps.

[0059] Step S4300: Return the standard metadata to the client to render the corresponding interactive interface based on the standard metadata, so that players can trigger the game access event through the interactive interface.

[0060] After successfully retrieving the standard metadata from the distributed cache, the standard metadata is returned to the requesting client in the appropriate format and protocol, supporting the client to complete the rendering of the interactive interface and ultimately providing the user with a visual game entry point to trigger subsequent game access events.

[0061] Through the above embodiments, by introducing a distributed caching architecture to store pre-standardized metadata, clients can obtain game information in a low-latency, high-concurrency manner, avoiding direct access to heterogeneous game provider data sources for each request, and significantly improving response speed and stability.

[0062] Based on any embodiment of the method in this application, it further includes: Step S5100: Obtain multiple heterogeneous game metadata, wherein the heterogeneous game metadata is provided by different game providers; This embodiment is used to build a unified game metadata service. First, it needs to acquire game information from diverse data sources. These different game providers may include externally partnered third-party game providers and the platform's own self-developed game platform. These data sources each use different data formats and interface specifications, resulting in significant heterogeneity. The differences in content and format of heterogeneous game metadata are reflected in multiple dimensions. Regarding identification systems, different providers use their own encoding rules to generate unique game identifiers, including purely numeric numbers, strings containing category prefixes, and UUID formats. In terms of naming conventions, the naming keys for text fields such as game names and descriptions differ. Regarding classification systems, each provider uses its own game type classification standards; for example, one provider subdivides shooting games into first-person shooters and third-person shooters, while another uniformly categorizes them as action shooters. Regarding media resources, the referencing methods for resources such as icons, screenshots, and videos vary, including relative paths requiring the concatenation of the base URL and complete CDN addresses. Regarding numerical precision, the effective digits and value ranges for statistical data such as ratings and star levels are inconsistent. Regarding time representation, fields such as creation time and update time use different time zones and formats, such as Unix timestamps, ISO 8601 strings, or local time formats. Regarding status encoding, online / offline status, maintenance status, etc., use different enumeration value definitions, such as 0 and 1, true and false, active and inactive.

[0063] Step S5200: According to the preset attribute extraction rules, extract the common attribute fields in the heterogeneous game metadata, and encapsulate the extracted common attribute fields into standard metadata based on the preset unified metadata structure. The attribute extraction rules define the mapping logic for identifying and extracting common attributes from heterogeneous game metadata. Common attributes refer to a set of attributes that exist universally across different data sources, have the same business meaning, but may be represented in different ways. These attributes cover dimensions such as basic game identity information, display information, category information, status information, and statistical information. For each common attribute, the attribute extraction rules specify in detail the matching mode, extraction priority, data transformation function, and default value strategy for candidate fields. Taking the game name attribute as an example, the rule can define prioritizing the search for the title field. If it does not exist, it will try the name, gameName, and displayName fields in sequence. After extraction, whitespace characters are trimmed and length is truncated. If all candidate fields are missing, an unknown game is used as the default value. Taking the game icon attribute as an example, the rule defines extraction from candidate fields such as icon, logo, iconUrl, and coverImage. If the value is a relative path, it is appended with the provider's preset basic URL prefix. If the value is a complete URL, it is used directly, while URL format validity is validated. If the validation fails, it is replaced with the platform's default placeholder icon URL.

[0064] The unified metadata structure is a standardized data model designed for the platform, clearly defining all fields, data types, constraints, and extension mechanisms included in the standard metadata. For example, it includes: a unique game identifier, distinguished from the provider's original identifier by a globally unique code assigned by the platform; a game name, including a dictionary of default language versions and multi-language localized versions; a game icon, including a list of URLs for multiple resolution versions and alternative placeholder images; a game type, using the platform's unified game classification system such as action, adventure, strategy, and role-playing enumeration values; provider information, including provider identifier, name, and official website link; game status, using unified enumerations for online / offline, testing, and maintenance statuses; and resource information, including structured descriptions of rich media resources such as screenshots, videos, and promotional materials. The process of encapsulating the extracted common attribute fields into standard metadata follows the definition of the unified metadata structure, that is, assigning values ​​from the common attribute container to the corresponding positions according to the order and type requirements of the field definitions. The encapsulated standard metadata is then serialized into a storage and transmission format.

[0065] Step S5300: Generate the metadata identifier of the standard metadata, and store the metadata identifier, along with the corresponding standard metadata, in a preset distributed cache.

[0066] After encapsulating the standard metadata, a unique metadata identifier needs to be generated for each piece of standard metadata, and an association between the identifier and the data needs to be established. This can be achieved using a hash algorithm or sequential encoding. Based on this metadata identifier, the standard metadata is stored in the corresponding location in a pre-defined distributed cache. The distributed cache can be implemented using a memory-based distributed storage system such as Redis Cluster or Memcached. By distributing the data across multiple cache nodes, it supports high-concurrency, low-latency read access and horizontal scaling of massive amounts of data. Storing standard metadata in a distributed cache accelerates access. When a client initiates a metadata retrieval request, it can directly read data from the memory-level cache, reducing the response time from tens of milliseconds in a disk database to sub-millisecond levels. Even with hundreds of thousands of concurrent queries per second, it maintains stable low latency, significantly improving user experience and throughput.

[0067] The above embodiments solve the integration challenges caused by differences in data formats among multiple game providers, enabling the platform to manage and present diverse game content from a unified perspective. Specifically, it achieves heterogeneity shielding; the standard metadata in the cache has been uniformly encapsulated, so regardless of the original game provider or proprietary format used, the client always faces a consistent data structure, eliminating the need to adapt to diverse data source interfaces, simplifying client development logic and reducing maintenance complexity.

[0068] Based on any embodiment of the method in this application, before returning the game metadata, the method includes: Step S4110: Obtain the target business identifier and metadata filtering conditions corresponding to the metadata acquisition request; The target business identifier is used to distinguish the specific business scenario of the requested metadata. Different business scenarios have different display requirements and business rules for the same batch of game metadata. For example, the main site game center of an application platform, the game channel embedded in an e-commerce page, and the traffic-driving page of a third-party partner channel all obtain game list metadata, but the main site needs to display complete game details and platform-exclusive event information, the e-commerce embedded page needs to highlight in-game item rewards related to shopping, and the partner channel needs to hide some sensitive information and add channel tracking parameters. The target business identifier can be represented by a predefined string encoding or a structured business encoding that includes dimensions such as business line, channel number, and version number.

[0069] Metadata filtering criteria are used to perform fine-grained filtering and sorting operations on top of the basic metadata set to meet specific client display needs. The types of filtering criteria are diverse, covering attribute filtering criteria (e.g., specifying the game type as card or board games), status filtering criteria (e.g., displaying only games that are online and not under maintenance), time range criteria (e.g., retrieving games newly launched within the last seven days), and keyword search criteria (e.g., game names or descriptions containing the keyword "adventure"). After obtaining the target business identifier and metadata filtering criteria corresponding to the metadata request, they are used to subsequently determine the appropriate secondary encapsulation rules and metadata processing.

[0070] Step S4120: Based on the secondary encapsulation rules corresponding to the target business identifier and combined with the metadata filtering conditions, perform secondary encapsulation processing on the game metadata obtained from the metadata cache to generate business metadata that matches the business requirements corresponding to the target business identifier as return data. Secondary encapsulation rules are predefined data processing configurations for specific target business identifiers, describing the complete transformation logic for deriving business metadata from standard metadata. Secondary encapsulation rules can be associated with target business identifiers and stored in a database. Each secondary encapsulation rule can include field selection configuration, field transformation configuration, field extension configuration, and output format configuration. Field selection configuration defines which fields in the standard metadata should be retained, which should be removed, and whether virtual calculation fields need to be added. For example, in an e-commerce embedded scenario, the provider's official website link field can be removed to prevent traffic leakage, but a product exchange ratio field can be added to support the conversion between game items and platform points. Field transformation configuration defines the value transformation rules for retained fields, such as converting the launch time to a relative time description (e.g., launched three days ago) or converting an absolute URL to a relative path of the current CDN domain. Field extension configuration defines the derived fields that need to be added, such as adding personalized recommendation reasons based on user profiles or adding limited-time tags based on current operational activities.

[0071] In practice, the various configuration processing rules defined by the secondary encapsulation rules are traversed, and field selection, field transformation, and field expansion operations are applied sequentially to each standard metadata record. This generates business metadata that matches the business requirements corresponding to the target business identifier.

[0072] Step S4130: Associate the business metadata with the corresponding target business identifier and store it in a preset business cache library, so that when the target business identifier stored in the business cache library matches the target business identifier corresponding to the metadata retrieval request, the corresponding business metadata can be directly retrieved from the business cache library.

[0073] After generating business metadata through secondary encapsulation, a caching mechanism needs to be established to avoid redundant calculations and improve the response efficiency of subsequent identical requests. The business cache library is a dedicated caching layer for storing the secondary encapsulated business metadata. When a new metadata retrieval request arrives, the business cache library is queried based on the target business identifier of the request to see if a corresponding target business identifier exists. If it exists, it is directly deserialized and returned, skipping the entire process of standard metadata retrieval, filtering, and secondary encapsulation, minimizing response latency.

[0074] Through the above embodiments, by introducing a layered processing mechanism of target business identifiers and secondary encapsulation rules, the same set of standard metadata can be flexibly adapted to diverse business scenario requirements, ensuring both the consistency and accuracy of data content and meeting the differentiated display requirements under different scenarios.

[0075] Based on any embodiment of the method in this application, after sending the access request to the corresponding game server, the method includes: Step S6100: Receive game event data generated by the game server executing the game interaction logic; After processing the access request and executing the corresponding game interaction logic, the game server generates asynchronous game event data. This game event data represents key state changes or business trigger points during game operation and needs to be promptly notified to the application platform to drive subsequent business processing. The timing and scenarios for generating game event data are diverse, covering all stages of the game lifecycle and all aspects of player interaction.

[0076] In one embodiment, the game interaction logic can be manifested as follows: when a player completes a specific goal in the game, such as clearing a dungeon, achieving an accomplishment, or leveling up a character, the game server generates a corresponding state change event, recording information such as the type of change, time, and previous and subsequent state values. In another embodiment, when a player acquires or consumes in-game currency, items, or equipment, details of the asset change are recorded, including the asset type, quantity, reason for the change, and associated transaction identifier. Executing these game interaction logics generates corresponding game event data, which the game server sends to the game access server for further processing.

[0077] Step S6200: Parse the game event data according to the heterogeneous protocol corresponding to the game server to obtain the original event data containing the abstract identifier; After receiving game event data pushed or pulled by the game server, a protocol parsing operation needs to be performed to convert the heterogeneously encoded network data into structured raw event data. Specific steps for heterogeneous protocol parsing can be found in the aforementioned specific embodiment regarding the parsing process of other data based on heterogeneous protocols, which will not be elaborated here. The final result is raw event data, which contains other raw event data.

[0078] Step S6300: Reversely restore the abstract identifier in the original event data according to the preset encryption rules to determine the real identifier representing the real identity information of the corresponding player; After parsing the raw event data containing the abstract identifier, an identifier restoration operation needs to be performed to convert the abstract identifier used for privacy protection back into a real identifier that can be recognized internally by the platform. This real identifier is used to represent the player's real identity information. The prerequisite for identifier restoration is to accurately identify the encryption rules used by the abstract identifier. In one embodiment, in addition to the abstract identifier itself, metadata fields such as encryption algorithm identifier and key version number are extracted from the raw event data. These fields correspond to the metadata embedded in the access request stage and are used to indicate the encryption rules used when the abstract identifier was generated. Based on the encryption algorithm identifier, the corresponding decryption rule is loaded from the encryption rule library, and based on the key version number, the corresponding decryption key or salt value is obtained from the key management system to ensure that the restoration operation uses the same algorithm and key materials as during encryption. Based on the decryption rule, the abstract identifier in the raw event data is converted into a real identifier for subsequent business logic processing.

[0079] Step S6400: According to the preset standard event template, the original event data containing the real identifier and event parameters is converted into standard event data in a unified format. Standard event templates are predefined event data specifications for those skilled in the art, describing the general structure and semantics of events in a way that is independent of specific game providers. The template system can adopt a layered design, including a basic event template defining common fields for all events, such as unique event identifiers, event timestamps, event type codes, and event source providers, and business event templates that inherit from the basic template and extend specific fields for particular business scenarios. For example, a game completion event template includes fields such as game identifier, completion time, score obtained, and a list of achievements; an asset change event template includes fields such as asset type, change quantity, post-change balance, and associated order identifier; and a social interaction event template includes fields such as interaction type, other user identifier, and a summary of the interaction content. Each field in the template defines its data type, value range, nullability, default value, and dependencies with other fields.

[0080] The conversion process begins by matching the event types in the original event data to the corresponding standard event templates. This mapping is achieved by querying an event type mapping table, which establishes a correspondence between each game provider's proprietary event type enumeration and the platform's standard event types. Based on the unified format defined in the standard event templates, the original event data is then converted into standard event data.

[0081] Step S6500: The standard event data is sent to the corresponding target downstream for corresponding business processing according to its event type.

[0082] After the standard event data format conversion is completed, the data is routed to the corresponding target downstream module according to the event type to drive specific business processing logic. The determination of the target downstream module depends on the mapping relationship between the event type and the downstream processing module. This mapping relationship is preset by those skilled in the art and supports precise matching based on event type or fuzzy routing based on event attributes.

[0083] The above embodiments shield the differences in protocols and heterogeneity in data formats between different game providers, enabling the unified reception, parsing, and processing of event data from various game servers, greatly reducing the complexity of integration and maintenance costs.

[0084] Please see Figure 2 This invention provides a game access device to meet one of the purposes of this application. It is a functional embodiment of the game access method of this application. The device includes an event response module 3100, a request conversion module 3200, a request sending module 3300, and a response receiving module 3400. The event response module 3100 is configured to respond to game access events triggered by player users, mapping the request parameters corresponding to the event into standardized protocol data according to preset standard rules. The standardized protocol data includes an abstract identifier used to hide the real identity information of the player user in the game access event. The request conversion module 3200 is configured to convert the standardized protocol data into an access request adapted to the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs. The request sending module 3300 is configured to send the access request to the game server corresponding to the game provider, driving the game server to execute corresponding game interaction logic based on the abstract identifier in the access request. The response receiving module 3400 is configured to receive the response data returned by the game server and parse the response data back into standardized response data according to the standard rules.

[0085] Based on any embodiment of the device in this application, the event response module 3100 includes: a template matching module, configured to match a standardized interface template corresponding to the standard rules according to the event type of the game access event, wherein the standardized interface template defines the abstract identifier field and business parameter field required by the event type; an identifier encryption module, configured to convert the real user identifier and / or real room identifier in the real identity information of the player user contained in the request parameters into an abstract user identifier and / or abstract room identifier according to a preset encryption rule; and an abstract identifier encapsulation module, configured to encapsulate the abstract user identifier, the abstract room identifier, and the business parameters contained in the request parameters according to the field structure defined by the standardized interface template to generate the standardized protocol data.

[0086] Based on any embodiment of the device in this application, the request conversion module 3200 includes: a protocol template determination module, configured to determine a protocol conversion template corresponding to the heterogeneous protocol of the target game provider from a preset protocol adaptation library based on the provider identifier in the request parameters, wherein the protocol conversion template defines the request structure, field mapping rules, and encoding format of the heterogeneous protocol; and a mapping and encapsulation module, configured to fill the field values ​​of each field in the standardized protocol data into the corresponding positions of the request structure according to the field mapping rules, and encapsulate according to the encoding format to generate the access request.

[0087] Based on any embodiment of the device in this application, the device further includes: an identifier conversion module, configured to respond to a metadata acquisition request and convert the metadata identifier corresponding to the request into a standard identifier based on an identifier mapping rule; a metadata acquisition module, configured to acquire the corresponding standard metadata from a preset distributed cache according to the standard identifier, wherein the standard metadata is obtained by encapsulating common data fields extracted from multiple heterogeneous game metadata through a unified metadata structure; and an interface rendering module, configured to return the standard metadata to the client to render the corresponding interactive interface based on the standard metadata, allowing players to trigger the game access event through the interactive interface.

[0088] Based on any embodiment of the device in this application, before the metadata acquisition module, the device includes: a heterogeneous data acquisition module, configured to acquire multiple heterogeneous game metadata provided by different game providers; a common attribute extraction module, configured to extract common attribute fields from the heterogeneous game metadata according to preset attribute extraction rules, and encapsulate the extracted common attribute fields into standard metadata based on a preset unified metadata structure; and a metadata storage module, configured to generate a metadata identifier for the standard metadata, and store the metadata identifier associated with the corresponding standard metadata in a preset distributed cache.

[0089] Based on any embodiment of the device in this application, before the standard metadata return module, the device includes: a filtering condition acquisition module, configured to acquire the target business identifier and metadata filtering conditions corresponding to the metadata acquisition request; a secondary encapsulation module, configured to perform secondary encapsulation processing on the game metadata obtained from the metadata cache according to the secondary encapsulation rules corresponding to the target business identifier and in combination with the metadata filtering conditions, so as to generate business metadata that matches the business requirements corresponding to the target business identifier as return data; and a metadata storage module, configured to associate and store the business metadata with the corresponding target business identifier in a preset business cache library, so as to realize that when the target business identifier stored in the business cache library matches the target business identifier corresponding to the metadata acquisition request, the corresponding business metadata can be directly retrieved from the business cache library.

[0090] Based on any embodiment of the device in this application, after the request sending module 3300, the device includes: a game event receiving module, configured to receive game event data generated by the game server executing the game interaction logic; an event parsing module, configured to parse the game event data according to a heterogeneous protocol corresponding to the game server to obtain original event data containing the abstract identifier; a real identifier conversion module, configured to reverse-engineer the abstract identifier in the original event data according to a preset encryption rule to determine the real identifier representing the real identity information of the corresponding player; an event format unification module, configured to convert the original event data containing the real identifier and event parameters into standard event data in a unified format according to a preset standard event template; and a standard data application module, configured to send the standard event data to the corresponding target downstream for corresponding business processing according to its event type.

[0091] To address the aforementioned technical problems, embodiments of this application also provide a computer device. For example... Figure 3 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, the processor can implement a game access method. The processor of the computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute the game access method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 3The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0092] In this embodiment, the processor is used to execute... Figure 2 The system defines the specific functions of each module and its sub-modules. The memory stores the program code and various data required to execute these modules or sub-modules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the game access device of this application. The server can call the server's program code and data to execute the functions of all sub-modules.

[0093] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the game access method of any embodiment of this application.

[0094] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0095] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0096] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A game access method, characterized in that, include: In response to a game access event triggered by a player, the system maps the request parameters corresponding to the event to standardized protocol data according to preset standard rules. The standardized protocol data includes an abstract identifier used to hide the real identity information of the player in the game access event. Based on the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs, the standardized protocol data is converted into an access request adapted to the heterogeneous protocol; The access request is sent to the game server corresponding to the game provider, and the game server is driven to execute the corresponding game interaction logic based on the abstract identifier in the access request. Receive the response data returned by the game server, and parse and restore the response data into standardized response data according to the standard rules.

2. The game access method according to claim 1, characterized in that, In response to a game access event triggered by a player, the system maps the request parameters corresponding to the event to standardized protocol data according to preset standard rules. This standardized protocol data includes an abstract identifier used to hide the player's true identity information in the game access event, comprising: Based on the event type of the game access event, a standardized interface template corresponding to the standard rules is matched. The standardized interface template defines the abstract identifier field and business parameter field required by the event type. The real user identifier and / or real room identifier contained in the real identity information of the player user in the request parameters are converted into abstract user identifier and / or abstract room identifier according to the preset encryption rules. The abstract user identifier, the abstract room identifier, and the business parameters contained in the request parameters are encapsulated according to the field structure defined in the standardized interface template to generate the standardized protocol data.

3. The game access method according to claim 1, characterized in that, Based on the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs, the standardized protocol data is converted into an access request adapted to the heterogeneous protocol, including: Based on the provider identifier in the request parameters, a protocol conversion template corresponding to the heterogeneous protocol of the target game provider is determined from a preset protocol adaptation library. The protocol conversion template defines the request structure, field mapping rules and encoding format of the heterogeneous protocol. According to the field mapping rules, the values ​​of each field in the standardized protocol data are filled into the corresponding positions in the request structure, and the data is encapsulated according to the encoding format to generate the access request.

4. The game access method according to claim 1, characterized in that, Before responding to game access events triggered by player users, the following should be included: In response to a metadata retrieval request, the metadata identifier corresponding to the request is converted into a standard identifier based on the identifier mapping rules. According to the standard identifier, the corresponding standard metadata is obtained from the preset distributed cache. The standard metadata is obtained by encapsulating common data fields extracted from multiple heterogeneous game metadata through a unified metadata structure. The standard metadata is returned to the client to render the corresponding interactive interface based on the standard metadata, allowing players to trigger the game access event through the interactive interface.

5. The game access method according to any one of claims 1 to 4, characterized in that, Before responding to a metadata retrieval request and converting the metadata identifier corresponding to the request into a standard identifier based on the identifier mapping rules, the process includes: Obtain metadata from multiple heterogeneous games, which are provided by different game providers; According to the preset attribute extraction rules, common attribute fields are extracted from the heterogeneous game metadata, and the extracted common attribute fields are encapsulated into standard metadata based on the preset unified metadata structure. Generate a metadata identifier for the standard metadata, and associate the metadata identifier with the corresponding standard metadata and store it in a preset distributed cache.

6. The game access method according to claim 4, characterized in that, The standard metadata is returned to the client to render the corresponding interactive interface based on the standard metadata. Before the player triggers the game access event through the interactive interface, the following steps are included: Obtain the target business identifier and metadata filtering conditions corresponding to the metadata retrieval request; Based on the secondary encapsulation rules corresponding to the target business identifier and combined with the metadata filtering conditions, the game metadata obtained from the metadata cache is subjected to secondary encapsulation processing to generate business metadata that matches the business requirements corresponding to the target business identifier as return data. The business metadata is associated with the corresponding target business identifier and stored in a preset business cache library so that when the target business identifier stored in the business cache library matches the target business identifier corresponding to the metadata retrieval request, the corresponding business metadata can be directly retrieved from the business cache library.

7. The game access method according to any one of claims 1 to 4, characterized in that, After sending the access request to the game server corresponding to the game provider, the process includes: Receive game event data generated by the game server executing the game interaction logic; Based on the heterogeneous protocol corresponding to the game server, the game event data is parsed to obtain the original event data containing the abstract identifier; Based on the preset encryption rules, the abstract identifier in the original event data is reversed to determine the real identifier representing the real identity information of the corresponding player; According to the preset standard event template, the original event data containing the real identifier and event parameters is converted into standard event data in a unified format; The standard event data is sent to the corresponding downstream target for business processing according to its event type.

8. A game access device, characterized in that, include: The event response module is configured to respond to game access events triggered by players. According to preset standard rules, the request parameters corresponding to the event are mapped to standardized protocol data. The standardized protocol data includes an abstract identifier used to hide the real identity information of the player in the game access event. The request conversion module is configured to convert the standardized protocol data into an access request adapted to the heterogeneous protocol based on the heterogeneous protocol corresponding to the game provider of the game to which the game access event belongs. The request sending module is configured to send the access request to the game server corresponding to the game provider, and drive the game server to execute the corresponding game interaction logic based on the abstract identifier in the access request. The response receiving module is configured to receive response data returned by the game server and parse the response data into standardized response data according to the standard rules.

9. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images