This is the first in what will be a series of posts describing how to connect gaming devices with related data services in the wot.io data service exchange™.

A marriage made in heaven

It should come as no surprise that gaming devices, whether of the console, mobile, or even maker variety, more than qualify as things in the Internet of Things. Nor should it be surprising that engineers love to play games. (I mean, how else could the world would have come up with something like this)?

So in a way, it was only a matter of time before we got around to a project that combined the two.

It all started with a game

In his essay "The Morals of Chess" (1750), Benjamin Franklin wrote:

The Game of Chess is not merely an idle amusement; several very valuable qualities of the mind, useful in the course of human life, are to be acquired and strengthened by it, so as to become habits ready on all occasions; for life is a kind of Chess, in which we have often points to gain, and competitors or adversaries to contend with, and in which there is a vast variety of good and ill events, that are, in some degree, the effect of prudence, or the want of it.

As much as we'd like to claim that the genesis of our gaming application series was rooted in such lofty ideals, the truth of the matter is that we chose chess primarily because projects like Deep Blue have popularized the understanding that chess presents a worthy challenge to demonstrate the true power of computing. (And you know chess is cool if Dr. Who had to win a game to save the universe).

Having thus selected the game, we set about to take up that challenge by combining chess with Android devices and the power of the wot.io data service exchange™.

A quick search on GitHub uncovered an open-source implementation of a chess game designed for Android devices. "Yes, this should do quite nicely," we thought to ourselves.

Adding real-time connectivity with PubNub

Unfortunately, however, while the original version of the chess game does support networked game play between two different devices, all of the communications are sent to a central FICS server.

Since our plans include integration with various wot.io data services and potentially even other IoT devices like local LED lights or clock timers, we realized that we would need to modify the game to somehow send game play events separately to each of these devices and services. And then if we wanted to add new devices or services later, we would need to update all of the game applications on all of the Android devices. Ugh.

"That doesn't seem to fit in very well with our thinking about these Android devices as IoT things" we thought. What our connected gaming devices really needed was a pub/sub approach to connectivity.

In other words, it sounded like a perfect fit for PubNub, one of the wot.io's data services.

We already knew that PubNub had a great story for developing multiplayer online games. So we wondered how difficult it would be to make it work with our Android application. Of course, we should have known they had that covered with their list of over 70 different SDKs

It was a relatively straightforward exercise to replace the networking logic with the PubNub SDK. In fact, PubNub Presence even enabled us to add player presence information—a feature that the original game did not have. You can find the PubNub enabled version of the source code for the chess game on GitHub.

So in very short order we were able to take an existing game and connect it to PubNub's real-time data platform with presence information—and in the process, effectively replace an entire purpose-built FICS service in the cloud. Not bad.

Routing gameplay event data with wot.io

Of course, after connecting the devices via PubNub, the rest was easy since wot.io already has a PubNub adapter.

Wait...you mean there are no more changes required to the application source code to connect to wot.io, its data services, or connected devices? I thought the only thing we did was to build a connected device application that knows how to connect to PubNub?

Exactly. All we needed was the name of the PubNub channel we had the game using, and the pub/sub API keys for our account, et voila! Game play events were available on the wot.io data service exchange, ready to be easily routed to or from any of the myriad data services that wot.io provides.

Yes, that's right. Because the wot.io adapter for PubNub is bi-directional, not only can data services subscribe to the game play events being transmitted by the devices over PubNub, but they can also publish messages that can be sent back to the devices via PubNub as well.

Any ideas for interesting data services that could take advantage of such power suggesting themselves to you yet? Well they did to us, too.

Next Time...

But before we get ahead of ourselves, as a first step, next time we'll see how easy it was to store all of the game play events in a data store using the wot.io data service exchange™.

Chess Photo Credit: By David Lapetina (Own work) [GFDL or CC BY-SA 3.0], via Wikimedia Commons