Today, more than ever, games are not a monolithic pile of code handcrafted by two bearded developers in the basement but rather a hodgepodge of libraries, plugins, SDKs, and APIs. This wide collection of 3rd party pieces of software are duct-taped to make a game. This process is great for making games faster and with more features, but it also introduces many dependencies.
Most vendors push their SDKs onto developers like desperate startup wannabes push business cards at a free networking mingler. We all know the result, your pocket gets full of trashy cards that sit in a drawer at the office for years while the companies pivot and die before the end of the party. SDKs are popular because they create ridiculous dependencies between the game client and the vendor. Worse, than business dependency is the increased risk of crashes in the game. Next time when someone tries to push their SDK onto your game ask for their API. Here are some benefits you will discover.
No Client Update Required
A well-designed game is divided between a game client and a backend server. The game client should focus on displaying the best gaming experience possible by using the client's device to the fullest. The backend server should manage all the data tasks including managing users, leaderboards, and game content. A good game client-server relationship is one that enables developers to add and remove APIs with minimal effort. This is important because changing code on a server is significantly safer. Unlike game clients which run on obscure Chinese devices the server is under complete developer control. Integration of the API on the server side is faster (no "testing on the device" or using Testflight) and keeps the game client disentangled from 3rd party vendors.
What this means is that if you are adding a leaderboard into your game, the game client should be developed agnostic of the leaderboard provider. So instead of adopting the latest leaderboard service provider’s SDK, look for a provider that has an API. Alternatively, if you have a developer who loves doing backend development, maybe he/she takes up the weekend project of writing an in-house leaderboard service. Having the logic and data for a leaderboard sit on a server makes it easier to switch if today you decide to move from the in-house solution to Playfab’s (or vice versa). The migration will be effortless, and the players will not even notice.
API Fits into Existing Game Logic
One way of comparing APIs to SDKs is that an SDK is a ready-made microwave control panel, with code that makes all the buttons, settings, and clockwork. An API, on the other hand, is a long list of small restful HTTP calls that provide minimal functions like: “time left to end cooking,” “list of preset buttons” (popcorn, +5min, defrost, etc.), and “stop.” What this means is that when you use an SDK you are often bringing a vendor’s buttons/screen into your game. While that sounds great at the beginning, if you choose to switch vendors you are looking at ripping the controls from your microwave and replacing with something else. Good luck finding another vendor whose microwave display fits into your vintage 2014 Emerson. The beauty of APIs is that because their functionality is broken down into tiny bits you can make the API fit just about every game. Back to the leaderboard example, you can quickly replace the user registration, leaderboard updating functionality, and the fetching of top 10 players, by finding equivalent API calls from the previous vendor. APIs do not govern the order of operations (too much), and these bits of data can be sprinkled into the game where it is most logical.
Easy to Control Dependencies - No Crashes
The best aspect of APIs is that they take advantage of one of the most tested pieces of code on any OS - the internet stack. The API, let’s not forget, is not code, it is a specification of how to use a third party “website” using restful HTTP requests. So an API cannot crash a game, only its implementation. The good news is that the HTTP requests are the most tested and stable system calls you can make. Another benefit is that unlike SDK’s which can generate hard crashes in the game, API’s at their worst return a non-response. API’s that become unresponsive can be easily checked for in the code, and the game can adjust. Finally, SDKs have complete access to the integrity of the game. All SDKs have complete freedom to open a pop-up window within your game or transfer data at any point in time (often lowering the framerate of the game). These freedoms are extremely hard to restrict as many SDK’s are not open-source making their functionality a complete black box.
When depending on a 3rd party service for data, it makes sense to implement their API on your game’s server. Yes, you might need to hire another developer to do the work because your rock star 3D game developer hates working with Java/Python/PHP (because he thinks that’s for losers), but this is a small price to pay. Finding and fixing game crashes are the biggest time sinks for an entire game team, and with SDKs, they are a challenge you never truly overcome. By keeping the APIs on your game’s server, you are creating an environment where making game changes are simple, safe, and completely under your control.