Every day, the ProgrammableWeb team is busy, updating its three primary directories for APIs, clients (language-specific libraries or SDKs for consuming or providing APIs), and source code samples. If you have new APIs, clients, or source code examples to add to ProgrammableWeb’s directories, we offer forms (APIs, Clients, Source Code) for submitting them to our API research team. If there’s a listing in one of our directories that you’d like to claim as the owner, please contact us at editor@programmableweb.com.
Nine APIs have been added to the ProgrammableWeb directory in the Cloud, Automation, and Messaging categories. Also added are SDKs for Optimal Payments, Nike+, Commercetools, and Maventa invoicing. Here, we summarize the new additions and how they can assist application developers.
APIs
RightScale is a cloud provider and management service that allows users to link public and private clouds. RightScale Cloud Pricing API provides a single source of pricing data for all public clouds supported by RightScale and all private clouds registered across a user's RightScale accounts. This API is listed under the Cloud category. See ProgrammableWeb's complete list of Cloud APIs.
Layer provides mobile and web messaging tools for developers. The service allows developers to build rich text messaging, voice, and video functionality into applications for communication. We've added two APIs provided by Layer to the directory. The Layer Client Rest API provides developers with methods for conversations, messages, read and delivery receipts, rich content, and error messages. Layer Client Websocket API provides tools for real time events to be received, allowing clients to receive messages, metadata and read receipts in real time. Other messaging operations are also supported. We've categorized the Layer APIs under the Messaging category. See ProgrammableWeb's complete list of Messaging APIs.
Wise is based in San Francisco and delivers tools and machine learning tech to back office tasks. The Wise REST API (Beta) offers micro task automation. API methods include describe, moderate and transcribe video and images, fetch contacts and emails from social profiles and more. the Wise API is categorized under Automation. See ProgrammableWeb's complete list of Automation APIs.
The National Environment Agency is responsible for preserving a clean environment in Singapore. The NEA Datasets API offers updated weather and environmental information. Get forecasts, earthquake, and ultraviolet information with it. Developers must register for an API key. We've listed this API under the Environment category. See ProgrammableWeb's complete list of Environment APIs.
Bit6 is based in Houston, and develops communications integration modules. Bit6 provides several APIs for developers to integrate the communications platform into existing applications. The Bit6 Backend API is a REST API and is used to implement a developer's application server with Bit6. Bit6 App API is used for client and server communications. Bit6 Authentication API provides several authorization methods including password, OAuth2, and phone number. The Bit6 APIs are listed under the Messaging category. See ProgrammableWeb's complete list of Messaging APIs.
hSenid Mobile Solutions provides the mChoice product suite to provide businesses with end-to-end Telcos services. hSenid Mobile SMS API allows developers to send and receive SMS messages from one application to another via a simplified REST bases API. The hSenid API is also listed under the Messaging category.
Frameworks, Libraries, and SDKs
Nike+ is a service that lets users track their running statistics and improvement over time, and track their individual goals along the way. Users can share training information with others, and setup virtual races with friends to compare times.
Developers can use the Nike+ API to access the raw data of their runs. The Nike+ JavaScript SDK allows application developers to communicate with the fitness monitoring features of the API. Nike also provides an Android SDK and iOS SDK.
Optimal Payments is an online payment service that supports PCI-compliant worldwide merchant accounts for accepting major credit and debit cards. The Optimal Payments Netbanx API service provides a secure, proprietary online payment gateway for processing payments and risk management services. Five SDKs to help developers integrate the API are available. The are: Netbanx Java SDK, Netbanx Ruby SDK, Netbanx Python SDK, Netbanx C# SDK, Netbanx PHP SDK, and Netbanx Node.js SDK, all provided by Optimal Payments.
Commercetools from Germany is an e-commerce platform for building custom online stores. They provide the Sphere.io API, which is billed as the "E-Commerce-as-an-API" platform. The company provides toolkits for building online stores, including the following.
Sphere.Io Node.js SDK allows developers to implement eCommerce features into applications using Node.js . Additional components include marketing tools, point of sale, and couch-commerce. Developers can access via OAuth2.
Sphere.Io PHP SDK offers API installation and integration guides with full documentation. On GitHub, developers can find a preparations section to work with Mac OS X, Linux, and Windows.
Sphere.Io Java SDK allows developers to communicate with the API for installation, modules, snapshots, and short-term roadmap. In the stability section, developers can find clarification for experimental features, dependencies, and HTTP client layer.
Maventa is a popular platform in the Nordics that provides electronic invoicing services. Their Maventa API allows developers to integrate with financial packages (SAP, Quickbooks, PeachTree, etc.), import data, test applications in the sandbox, and more. Two SDKs for use with the API have been added to the directory.
Maventa Node.js SDK by developer Niklas Närhinen allows developers to integrate e-invoicing features included in the SOAP API into payroll applications. Methods display code to add company's name, create invoice, and organize lists between invoice dates.
Maventa Java SDK by Jussi Pöri lets developers implement e-invoicing features into Java applications.
There are many mobile games on the app stores and desktop games on distribution platforms such as Steam -- with more launched every day. The very best of these games keep users entertained for weeks and months at a time. The hallmark of these games is how well they enable users to compete with friends and others around the world.
This tutorial will walk you through how you can use Heroic Labs’ Shared Storage API with Unity to create games in which users can compete against each other. The game we’re using for inspiration is Boom Beach -- a mobile strategy game in which players build bases, attack other players’ bases, and defend their bases from attack. We’ll call our sample game Battle Town.
Our game will have a Medieval setting where players can build up armies consisting of 5 types of units: farmer, archer, knight, captain, and healer. Normally, we’d have many more unit types with different skills, damage output, etc. -- but let’s keep the code simple.
We’ll use C# and the Heroic Labs SDK to work with the Shared Storage API. To get started with Heroic Labs you can create an account for free in the Dashboard. When you’ve logged in, you then create a game in the service and grab an API key from the "Game Detail" view. This API key is used to authenticate the SDK with the API.
Now, we need to set up the game project in Unity. I won’t be able to cover all of the setup involved with Unity or how to build the UI or graphics for our battle game, but there are lots of tutorials you can use to cover other parts of the game development work. We’ll work heavily in Unity scripts -- which are attached to game objects -- and write our C# code.
The first thing we need to do is to initialize the SDK with our API key. This must be done as early as possible in the game -- ideally at game startup. (I’ll use an example key, but you will need to use a valid one from the Dashboard.):
Client.ApiKey = "215bff112839448cb4ccf716605c94b2";You can test that the API key is valid and works with a quick "ping" request to the API:
Client.Ping ((status, reason) => {
Debug.LogFormat ("Request failed with '{0}' and '{1}'.", status, reason);
});The code above will only display a log message if you’re unable to connect to the API. If this happens, use the "reason" in the output to discover why and adjust your code as needed.
With the SDK configured and Unity set up, let’s return to our game design. Every player will need to be logged in to Battle Town to play. There are a number of ways we can solve this problem; some solutions involve Facebook or other social network integration -- but for this tutorial, we’ll keep it simple and use a unique device ID (UDID). For other options, have a look here.
UDIDs can be unreliable identification sources within mobile games because they can change after a device update. We’ll place a copy of the UDID in device storage so that it can be referenced by the game in the future if the user needs to re-authenticate.
Even with this solution, it’s possible that we won’t be able to recover a user’s account if the device storage is cleared and a device update occurs; consider one of the other account creation options in the Heroic Labs API:
string uid = PlayerPrefs.GetString("UID");
if (string.IsNullOrEmpty (uid)) {
uid = SystemInfo.deviceUniqueIdentifier;
PlayerPrefs.SetString ("UID", uid);
}
Client.LoginAnonymous (uid, (SessionClient sessionClient) => {
// we have a SessionClient to make requests with
// cache this for later use in the SceneGraph
}, (status, reason) => {
Debug.LogErrorFormat ("Could not login user with ID: '{0}'.", uid);
});The authentication of the user returns a "SessionClient" in the SDK which handles all API operations that require an active user. We need to have a player logged in so that we can share their army with other players for battles. At this point, let’s go back to our Battle Town game and outline how the gameplay mechanics will work.
Each player has a “town” that must be protected from other players -- all of whom may build units to defend their towns and explore the surrounding land for other towns to attack. These other towns belong to others. When players successful attack, they will be rewarded with points to spend on new units and upgrades to their towns.
From a game balance perspective, we want to make sure that players can only find and attack towns that match a similar level to their own. This ensures that new players aren’t discouraged from playing when they first join the game.
Now, we have some game rules in mind: We’ll start by sharing the user’s army and town information with other players. This is done with a simple Shared Storage write request to a key for the user. Before we dive too deeply into what that code looks like, let’s go over Shared Storage basics:
Shared Storage is a large distributed collection of objects (with keys). Each object belongs to a specific user -- and users can have many objects, each identified by its own key. These objects are split up into two sections: public and protected. The public section of an object can be written to from the SDK by game clients, while the protected section can only be read by the SDK. The entire collection of objects can be searched over by any player in the game.
To keep our code straightforward, we’ll store information on a player’s town and their army in a key called "TOWN." This information will be updated by the game client whenever the current player’s town changes and should also be updated once at the startup of each play session.
I’ll use an IDictionary to store the information, but you’ll probably want to define your own classes to represent different parts of your game state:
Dictionary<string, object> data = new Dictionary<string, object> ();
data.Add ("level", 6);
data.Add ("last_active", 1449124938073); // A timestamp.
data.Add ("tree_count", 10);
// Add other data here for the Town.
string storageKey = "TOWN";
sessionClient.SharedStoragePut (storageKey, data, () => {
Debug.LogFormat ("Successfully stored town data.");
}, (status, reason) => {
Debug.LogErrorFormat ("The request failed with '{0}' and '{1}'.", status, reason);
});Now we have a way for all players to share their towns and armies with others in the game. The next big piece of the puzzle to solve is a way to “find” towns as players explore the land around their own towns.
Let’s imagine this part of the game as a top-down world map with tiles that can be clicked on to "reveal" the surrounding landscape. Some of these tiles will show resource gathering objects such as mines and farms, but others will contain other players’ towns to battle. You might also use an energy bar to control how much exploration a player can conduct within a given play session.
Inside code written to handle the reveal controls on the world map, we’ll add code that will query all "TOWN" keys for other players and filter them to match specific conditions such as those mentioned above (e.g., players found for battle must be within 3 levels of the current player):
string query = "value.level: [3 TO 9]";
sessionClient.SharedStorageSearchGet (query, (SharedStorageSearchResults results) => {
foreach (SharedStorageObject result in results) {
Debug.Log ("Found player and town data: {0}.", result.ConvertPublic());
}
}, (status, reason) => {
Debug.LogErrorFormat ("The request failed with '{0}' and '{1}'.", status, reason);
});The code above uses a simple query language based on Lucene, which is part of the Heroic Labs API. The query language makes it very easy to express search operations over all objects in the datastore. Some examples of queries we could use in the game include:
The "^2" is known as a "boost" in Lucene terminology; what we have requested is for objects that return with a lastActive field greater than 1449124938072 to come back higher in the list of objects we receive.
You can see more examples of queries that can be performed here and also have a look at the documentation on Shared Storage.
The results we get back can then be used to display revealed towns on the map and give the current player the option to challenge them to battle. The actual battle simulation could be auto-run by the game or have options to let a user manage the combat.
When a battle is completed, we can reward the winner -- and warn the loser that there has been an attack, and that revenge would be a good option! This could be achieved with push notifications or in-game messages.You may also want to look at other Heroic Labs APIs that can help with this part of the game.
This tutorial covers a very fun and easy way to build player-vs-player (PvP) games in Unity. Beyond our fictional Battle Town game, you could also share player-generated maps, custom board game types, or other kinds of information in games between all or some of your players. The possibilities really are endless -- and I’ll leave it to your imagination to see how you could build the next hugely successful game!
