How to quickly and efficiently access the SDK-the overall idea and architecture, and the overall idea architecture of the sdk

How to quickly and efficiently access the SDK-the overall idea and architecture, and the overall idea architecture of the sdk

Question: Many people who develop games probably take over the Channel SDK, UC, dangle, 91, Xiaomi, 360 ...... according to statistics, there are currently no more than 100 channels in the domestic market, and there are also some small channels without sdks. The SDK access methods for each channel are mostly the same. However, these differences allow SDK access to produce endless variables. Therefore, if you have no experience or have never been pitted by the SDK before accessing the SDK, You will be lucky when you see this series of articles. You can avoid this. If you have been pitted before and are still being pitted, now is the time for your relief.

There is not much technical knowledge to complete the access to an SDK, but it can connect to 100 sdks, which is easy to maintain, clear in structure, secure and reliable. Once and for all, it is not that easy. This is why there are so many packaging tools in the world, and the SDK access methods are different.

With the outbreak of mobile games, there are more mobile games and more people are being pitted, so there will always be some talented people who are unwilling to suffer and start to use their brains, seek a unified SDK access framework that can serve both yourself and others. As the saying goes, there is a need for suffering. Therefore, SDK access to this small market (or this market is also very small) has emerged, such as prism SDK, AnySDK, easy to connect and other companies or institutions dedicated to SDK access. They think they are the salvation of the times. Their appearance will bring a bright future to the children's shoes who are still suffering from SDK access. But in fact?

This unified SDK access framework is in conflict with the actual situation. They all require that, when game developers access their abstract framework, Server login authentication and payment callback go through their servers. However, this makes almost all game developers discouraged. Why? Because, for game developers, what is more important than user data and payment data? Isn't it worse to let the data go through someone else's server than to put their wife in another's house for two nights?

However, things like prism sdk and AnySDK are really good. No, I feel a little heartache. So the question is, can you implement and maintain a set of frameworks like the prism SDK or AnySDK as your own unified SDK access solution? The answer is, of course. However, I had to work hard once, and then I was relieved. Because for the first time, each channel SDK still needs to be accessed by itself. However, when you think of these things, you can develop and maintain them on your own. One word: Be steadfast. Oh, it's wrong. It's two words.

In this series of tutorials, we will implement a set of things similar to the prism SDK or AnySDK from start to end. So let's analyze what we need to implement when we access an SDK.

1. First, the client needs to access multiple sdks. In order to reuse multiple games, we cannot directly access each SDK in the game. Instead, we need to separate the access between the game and the SDK.

2. Since SDK access and game separation are mentioned above, we need to abstract an SDK access framework. The game only needs to access this framework, and then each channel SDK can implement this framework.

3. We need to implement a packaging tool, which cannot contain 100 channel packages. Manually click package one by one, which will lead to death.

4. On the server side, we also need a unified user logon authentication center and a unified payment center to support multiple games.

Therefore, we should have the following parts:

1. Unified SDK access framework

2. SDK access implementation

3. One-click packaging Tool

4. Unified login authentication center and payment center

Well, the overall idea is there. We are also similar to the prism SDK and AnySDK. How can we have no name? Let's call him The U8 SDK. Now let's analyze it again. Generally, there are two major parts of SDK access. One part is login, and the other part is payment. The same is true for our u8 sdk. We need to plan the entire login process and the payment process.

Let's first look at the login process. If you don't use this framework, you can directly access the SDK. What is the login process? Here we can look at the uc sdk's login flowchart:

1. the "game client" calls the "SDK client" Logon function. The "SDK client" directs the user to enter the user name and password. When the user logs on using the "UC account, the "SDK client" calls the "SDK server" interface for identity authentication;

2. After the "SDK server" password is verified, the sid and user information (including ucid and user nickname) are returned );

3. After the "game client" receives a callback notification from the "SDK client", you can obtain the sid from the "SDK client;

5. The "game server" can request to the "SDK server" for sid verification (call the user session verification interface. For details, refer to "UC Youshi game SDK development reference manual-server interface");

6. The "SDK server" returns the sid verification result and the corresponding ucid to the "game server ";

7. The game server returns the sid verification result, ucid, and user nickname to the game client"

Now, we want to join our unified login authentication center. Moreover, our framework is designed for multiple games. Therefore, we cannot allow the game Server to interact directly with the SDK Server of each channel. Therefore, we have added a uniform login authentication Server called U8 Server. Then, we will design the u8 sdk login authentication process:

1. The client accesses the abstract SDK framework. Based on the specific SDK channel, the login interface is called, and the user name and password are input for SDK login.

2. If the SDK is successfully logged on, information such as sid will be returned.

3. The game client can obtain this sid through the SDK abstraction layer interface.

4. The game client uses this sid and the appid, channel number, and other information previously applied to the u8 server to access the u8 server through Http for login authentication.

5. The u8 server authenticates the corresponding SDK server based on the currently passed appid and channel number.

6. If the SDK server passes authentication, the user information on the SDK server is returned.

7. U8 Server obtains the user information, generates and stores the unified user information of u8 server. Then, return a valid token to the client.

8. The client uses this token to access the game server (most of which are game login servers)

9. The game server uses this token to log on to the u8 server for authentication.

10. If the u8 server determines that the token is valid, the user information returned to the current user of the game server

11. The game server obtains the user information to prove that the current login is successful. The game server returns the list of client servers and other data. The login is successful.

Let's look at the sequence of login authentication to see the sequence of the process more intuitively:

This new login process is a simple comparison with the old login process. The old login authentication process requires interaction with each channel SDK for each game server. However, in the new process, each game Server only needs to interact with the U8 Server, and all the third-party SDK login authentication operations are performed by the U8 Server. Similarly, for each game, the client only needs to access the abstract SDK access layer, instead of accessing the sdks of each channel. All client operations and server operations only need to be performed once.

Next, let's take a look at the payment process. If this framework is not used, we can directly access the SDK and what the payment looks like. We will take the uc sdk as an example:

1. The "game client" calls the "SDK client" API to submit the recharge information. The "SDK client" instructs the user to select different recharge methods and enter the recharge amount.

2. The "SDK client" submits sid, gameid, serverid, and corresponding recharge information to the "SDK server ";

3. After the "SDK server" receives the recharge request, it returns the corresponding "Order Number" to the "SDK client ";

4. The "SDK client" will notify the "game client" of the corresponding recharge "Order Number ";

5. The "game client" submits the received "Order Number" and related game role information (determined by the game) to the "game server ";

6. After the "SDK server" processes the recharge request, it will notify the "game server" of the recharge result asynchronously.

7. The game server returns a SUCCESS or FAILURE sign to the SDK server ). The success or failure of the recharge result has nothing to do with the receipt Mark here. No matter whether the recharge is successful or not, you only need the "game server" to receive and identify the recharge result notification, should Return SUCCESS to the SDK Server)

Now, we want to join our unified payment center for multiple games. Therefore, we cannot allow game servers to directly interact with SDK servers in each channel, we also added a unified payment Server. We also added the functions of the payment center to the U8 Server. Let's look at the new payment process:

1. The game client first requests the game server to recharge

2. The game Server uses the user's id and some data that needs to be returned as is after the payment is successful to access the U8 Server to apply for an order number.

3. The U8 Server generates a unique order number and an order record in the database. The status is in the payment status.

4. The game server returns the order number to the client.

5. After obtaining the order number, the game client calls the payment interface of the SDK abstract interface and the corresponding SDK payment interface with the order number and the game recharge data.

6. before calling the SDK payment interface for the channel implementation of the current SDK, You need to place the order number you just placed in the Custom parameters of the channel SDK payment parameters. Each channel is the same.

7. If the channel SDK payment is successful, a status is immediately returned.

8. At the same time, the channel SDK server asynchronously notifies the game developer of the payment callback address. Note: During Game access, this callback address must be set to an address provided by u8 server.

9. The u8 server receives a recharge callback and immediately returns a success or failure status to the channel SDK server based on the verification result.

10. The u8 server then queries the corresponding order information based on the orderID in the Custom parameter, and then obtains the current user information and the corresponding Game Information Based on the order information, the payment callback address provided by the game server to the u8 server before the game access is called. For this callback address, the game server only needs to provide one to the u8 server. Because the game server only interacts with the u8 server.

11. When the game server receives a callback and verifies whether the callback is successful, a message indicating success or failure is returned to the u8 server. At the same time, add game coins to the corresponding players.

In this way, by comparing the two payment flowchart, we can clearly find that the new process can be accessed only once, and multiple games can be used together. This is the payment process of our framework. Let's send a sequence chart to view the entire process more intuitively:

Therefore, by analyzing the functions to be implemented in the entire framework, we have designed a set of architecture that can implement unified SDK login authentication and payment center. Then, we will implement each part in detail. Including the abstract SDK access framework, how the game client connects to this abstract SDK access framework, how the SDK of various channels is integrated into this SDK framework, and how to implement one-click packaging tools, how to implement this unified login authentication center and payment center.

Author: Xiao Hei