Previously we covered Using Google Play Games on the Web and how Google Play Games services[3] can be used for web games[1]. There was a lot of interest on that article, mostly about providing UI components, which is a project that I have started, when I am not working on the refactor of Gaming Engine - Snake Demo v2. However, before building a UI, the API needed to be cleaned up, making the authentication easier and chainable callbacks without needing function nesting. The whole framework will be available on github[2] as I work on it, but for starters lets explore version 0.1, The API Improvements.

How it works…

The API is still a little rough, but I am pretty happy with how much easier it is to use than the original. The only part of the API that I am not happy with is integrating the authentication callback function with Google. Since the Google API requires the auth callback be attached directly to window and not another object on window (you cannot use GoogleGamesApi.authCallback directly). Consequently, GoogleGamesApi.authCallback must be set to a globally available variable and that global variable set to the google-signin-callback meta.

When the user authenticates, Google will automatically call GoogleGamesApi.authCallback and it will handle authentication. Calling any of the APIs when not authenticated will throw an GoogleGamesApi.ApiUnauthenticatedException error. The GoogleGamesApi.runWhenAuthenticated should be passed a callback function, which will execute as soon as the API authenticates or immediately when already authenticated. The callback will be passed a single argument, the GoogleGamesApi object for ease of use, instead of forcing the developer to call the global variable (GoogleGamesApi).

Inside the GoogleGamesApi.runWhenAuthenticated callback all API calls are available on oApi or GoogleGamesApi. These are the same object, so they can be used interchangeable, but be consistent. Calls to the API simply execute the underlying Google Play Games API. At the time of this writing, the first argument of all methods is the callback function (to pass the response into) and the second argument is an optional object for passing required/optional arguments to the Games API (these are defined on the API website[3]). I point this out, because while this makes most sense now, I may change the API signature if it something else makes more sense after more adoption, so check the github documentation. If a required parameter is not included, the underlying Games APIs will throw an exception.

Using the GoogleGamesApi object will make all API calls asynchronous, each returning as soon as the data is available. However, each API call also returns a new instance of itself, which can be chained (as shown in the last example). When chaining methods they use a promise-like system, waiting for the call to complete (and the callback executed), before running the next API call. This is useful when you have data in a dependant API call that references something from another API call (usually object definitions and instances, or a player object). This is one of the main failings of the Games API.

There’s more…

This is just the groundwork for building an Android inspired web UI. There is a lot to build still, and improvements to be added to the API layer. Some things that I expect to add soon are better authentication error handling (at least documenting a good auth recovery pattern), additions to the promise layer (such as a fail function), and possibly better caching. For the latter, the API currently leverages the browser URL caching, but there is probably room for an in memory map or a local storage technology. Anyway, there is loads more to come, but I wanted to start the project and share it with the community.

References

I have been avoiding writing about ECMAScript 6 (E6)[6] for the past couple of years. This is mostly because the standard was not finalized, and consequently most browsers/engines were implementing different and often unstable versions of the various new features. With the E6 spec stabilizing almost a year ago now[1] and the final release date scheduled sometime later this year[1], I expected most browsers/engines would have implemented much of it, with bake ...

Now that we understand the Recycler Object for Object Pool Pattern, we can build the logic for managing the object pool. An object pool is a simple API that manages recycling and fetching recyclable objects. There are two common models for object pools, one with a fixed number of objects that errors if too many objects are requested, and the other (more flexible approach) is to use the object pool for a fixed number ...

One of the many new HTML5 APIs slowly being implemented by browsers is the Network Information API[2]. It exposes information about the type of network that the connecting device is using. In theory, this allows developers to optimize content around the connection speed of the user. However, as with most HTML5 APIs it is supported only by some browsers with/without prefixes, and has a legacy implementation, so a polyfill is useful when working with ...

Have you ever included a library and wonder, "how much did this library add to the window object", or passed an object into a function and asked yourself, "did that function modify my object"? Instead of reading the source code, this article shows a quick trick for answering these questions.

How do it…

For starters we need a function to count the number of properties on an object:

As many of you know, I now work for Google on the Play Games Team. We provide APIs for game developers, implementing useful features like leaderboards and achievements, so the developer doesn't have to. While many Android developers are using our services, adoption on the web could be better, so lets take a look at how to integrate the Google Play Games Services achievements into a web game.

Getting ready

One of the less understood, but powerful feature of browser events are their phases. According to the W3C level 2 spec there are three phases[1]: AT_TARGET=2, BUBBLING_PHASE=3, and CAPTURING_PHASE=1. Most browsers also implement a fourth phase[2]: NONE=0.

Getting ready

Just a quick note that everything discussed in this article is for modern browsers (all browsers except IE <9). Prior to IE 9, Internet Explorer used its own event system, instead of conforming ...

I was reviewing the browser event stack the other day and was reminded of a rarely used feature of addEventListener that allows developers to autobind the execution context object, instead of requiring a call to bind or using a library, that is worth sharing, if you weren’t already aware.