Teach you fast and efficient access to sdk--general ideas and architecture

Preface: A lot of people do game development, estimates are more or less to take the Channel SDK, what UC, when Le, 91, millet, 360 ... according to statistics the domestic market is currently less than 100 channels, but also includes some small channels without SDK. Each channel SDK access method, much is similar. However, it is these small different, and let the SDK access, creating endless variables. So, before accessing the SDK, if you have no experience, or have not been trapped by the SDK, then when you see this series of articles, you are lucky, you can avoid all this. If you've been in a hole before and you're still in the pit, now is your time to be free.

The completion of an SDK access is not much technical content, but access to 100 SDK, and can be maintained easy, clear structure, safe and reliable, once and for all is not so easy things. This is also why, there are so many packaging tools introduced in the world, the introduction of the SDK access method ..... And it's not the same.

With the eruption of the hand-tour, do more hands-on tour, more people are pits, then there will always be some capable person unwilling to its bitter, began to start the brain, to seek a set of services to themselves, can also serve others of the Unified SDK Access framework. As the saying goes, there is pain, there will be demand. So, the SDK access to this small market (or the market is very small) has sprung up, such as Prism SDK,ANYSDK, easy to connect, such as the Special SDK access to the company or organization. They think they are the salvation of the Times. Their appearance, will give the vast number of children still suffering from the SDK access to bring a bright child shoes. But what is the truth?

This unified SDK Access framework itself, there is a contradiction with the actual situation of the place. Because, they are all without exception, the game developers in the access to their abstract framework, server-side login authentication, and pay callbacks are going to their servers. But that's the point, which is prohibitive for almost all game developers. Why is it? Because, for game developers, what is more important than user data and payment data? Wouldn't it be harder to get this data to go through someone else's server than to let their wife sleep two nights in someone else's house?

But, like a prism sdk,anysdk that set of things, really good. No, there is a feeling of heartache. So the question is, can you implement and maintain a framework like the Prism SDK, or ANYSDK, as the company's own unified SDK access solution? The answer is, of course I can. It's just that I need a hard time and then I'm free. Because for the first time, each channel SDK still has its own access. However, think of these things are their own development, their own maintenance, a word: practical. Oh, wrong, it's two words.

In this series of tutorials, we're going to implement a set of things like the Prism SDK, or ANYSDK, from beginning to end. So, let's start by analyzing what we need to do to access an SDK.

1, first, the client needs to access a variety of SDKs, in order to be able to reuse a variety of games, we can not directly in the game to access each SDK, but need to separate the game and SDK access.

2, the above since the SDK access and game separation, then we need to abstract an SDK access framework, the game only need to access the framework, and then each channel SDK to implement this framework.

3, we need to implement a packaging tool, it is not possible to 100 channel package, manually one by one to click Package, it will be dead.

4, server side, similarly, in order to support a variety of games, we need a unified User login Certification center, and a unified payment center.

So, we have this set of things that should have the following parts:

1. Unified SDK Access Framework

2, each SDK access implementation

3, one-click Packaging tools

4. Unified Login Certification Center and Payment Center

Good, the whole idea has, we this is also and prism sdk,anysdk almost the thing, how can no name? Let's call him U8 SDK. Now, let us analyze, the General SDK access has two major parts. Part is landing, part is payment. Then our U8 SDK is naturally the same, we need to put the entire landing process, and the entire payment process to a good plan.

We first look at the landing process, if you do not use the framework, direct access to the SDK, the landing process is what? Here we can look at the UC SDK his login flowchart:

1. "The game client" invokes the "SDK Client" login function, "SDK Client" directs the user to enter the user name password, when the user logs in using "UC account", "SDK client" calls the "SDK Server" interface for authentication;

2. "SDK Server" Password authentication after the return of the SID and user-related information (including: ucid, user nickname, etc.);

3. "Game client" after the "SDK client" callback notification, the "SDK client" to obtain the SID;

5. "Game server" to the "SDK Server" request authentication sid (call user session authentication interface, see "UC excellent video game SDK Development Reference Manual-Server Interface");

6. The SDK server returns the results of the SID verification and the corresponding ucid to the game server;

7. "Game server" returns the SID verification result and Ucid, user nickname to "Game client"

Well, we now want to join our Unified login Certification center, and, our framework, itself is for a variety of games, so, we can not let the game server directly and each channel SDK server interaction, so we add a unified login authentication server, call U8 server. So, let's design the login certification process for the U8 SDK:

1, the Client Access Abstract SDK framework, according to the current specific SDK channel, call the login interface, and then pass in the user name and password, the SDK login operation

2, the SDK login success, will return SID and other information

3. The game client can get to this SID through the interface of the SDK abstraction layer

4, the game client holding this SID and access to U8 server before the AppID, channel number and other information, HTTP access U8 server for login authentication.

5, U8 Server according to the current delivery of AppID, channel number, to the corresponding SDK server certification

6, the SDK Server authentication is successful, will return to the SDK server over there user information

7, U8 server to get the user information, generate a U8 server unified user information and storage. Then, a valid token is returned to the client immediately.

8, the client take this token, to access the game server (most of the game landing server)

9, game server, take this token to U8 server for login authentication.

10. U8 server determines token valid, then returns the user information to the current user of the game server

11, the game server to obtain user information, prove the current login success, return to the client server list and other data, landing success.

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

This new landing process is a simple contrast to the old login process, as you can see. The old login authentication process, for each game server, need to interact with each channel SDK. However, the new process, each game server only need to interact with U8 server, all by U8 server for the third-party SDK login authentication operation. Similarly, for every game developed, the client only needs to access the abstract SDK access layer, and no longer needs to access the SDK for each channel. All client operations, and server-side operations, only need to do that one time on OK.

So, let's take a look at the payment process, and if we don't use the framework, we're directly connected to the SDK, and what the payment looks like, we take the UC SDK as an example:

1. The "Game client" invokes the "SDK client" API interface and submits the top-up information; "SDK Client" guides the user to select a different recharge method and enter the amount to recharge.

2. The SDK client submits the SID, GameID, ServerID, and the corresponding recharge information to the SDK server;

3. The "SDK Server" will return the corresponding "order number" to "SDK client" after receiving the recharge request;

4. "SDK Client" will call back "game client" corresponding to the "order number";

5. "Game Client" will receive the "Order number" and the relevant game role information (by the game's own discretion) submitted to the "game server";

6. After processing the recharge request, the SDK server will notify the "game server" top-up result asynchronously.

7. "Game server" returns to the SDK server whether the flag (success or failure) has successfully received the top-up result. The success or failure of the top-up result is not related to the receive flag here, regardless of whether the top-up is successful, as long as "game server" can receive and identify the top-up notification, you should return to the "SDK Server" Success Flag (SUCCESS)

So, we are now going to join our unified Payment Center, also for a variety of games, so we can not let the game server directly with each channel SDK server interaction, we also added a unified payment server, we put the function of the payment center also added to U8 server. Let's look at the new payment process:

1, the game client, first request the game server to recharge

2. The game server takes the user's ID and some data that is returned after successful payment, to access the U8 server application order number

3, U8 server generates a unique order number, and the database generates an order record, status is the payment status

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

5, the game client, get the order number, with the order number and the game to recharge the relevant data, call the SDK Abstract interface payment interface, call the corresponding SDK payment interface, to recharge operations.

6, the current channel implementation of the SDK before invoking the SDK payment interface, you need to put just the order number, the Channel SDK payment parameters in the custom parameters. This is the same for every channel.

7, Channel SDK payment success, immediately return to a status

8. At the same time, the Channel SDK server will asynchronously notify the game developer of the payment callback address set. Note that when the game is plugged in, this callback address is set to an address provided by U8 server.

9, U8 server receives the recharge callback, according to the verification result and so on, immediately returns a successful or failed status to the Channel SDK server.

10, then U8 server according to the custom parameters in the OrderID, query to the corresponding order information, and then according to the order information, to obtain the current user information and corresponding game information, and then call access to the game, the game server provided to U8 server payment callback address. This callback address, the game server only need to provide a to U8 server on it. Because the game server interacts only with U8 server.

11, the game server receives the callback, verifies the success or not, inside returns to the U8 Server a success or the failure information. At the same time, to the corresponding players to add game currency.

In this way, we compare two payment flowchart, you can clearly find that the new process, you can only access once, after a variety of games, can be used together. So this is the payment process for our framework. We'll send a sequence diagram to see the whole process more intuitively:

So, through the analysis of the function that the framework needs to implement, we design a set of architecture that can realize the Unified SDK login authentication and payment Center. So then, we will be specific to achieve each part. Including abstract SDK Access framework, how the game client access to the Abstract SDK Access framework, how the various channel SDK integration into the SDK framework, how to implement a key packaging tool, how to achieve this unified login Certification center and Payment Center.

This article small black

Teach you fast and efficient access to sdk--general ideas and architecture