Stay organized with collections Save and categorize content based on your preferences.

Google Play Games C++ SDK



The main entry point for Play Game Services functionality is the GameServices class. GameServices instances are created with GameServices::Builder. See GameServices

Methods that access or mutate the state of the entire GameServices session live in the GameServices class itself.

Other functionality is indirected through a set of per-feature managers. These managers group related functionality together; they contain no user-visible state themselves. Managers are returned by reference, and have lifetime controlled by the containing GameServices instance. As such, client code should never hold onto a manager reference, but instead hold on to the GameServices instance. See Managers.

Data is returned via immutable value type objects. These values reflect a consistent view of the underlying data at the point in time the query was made. See Value Types.

Threading Model

Unless otherwise noted, all GameServices methods and Manager methods are threadsafe and asynchronous. They can be called on any thread without external locking, and will execute in an order consistent with their invocation order. In general, mutator methods (those that change state) use a fire-and-forget model. Accessor methods (those that read state) come in two major variants. The first variant (with names like GetProperty) asynchronously supply their results to a provided callback; the second variant (with names like GetPropertyBlocking) synchronously return their results to the calling thread. Accessors see the results of all mutators that have been called prior; however, the mutator may or may not have modified the remote Game Services state at any given time.

All user callbacks (whether one-shot callbacks supplied as arguments to accessor methods, or multi-use callbacks configured at GameServices build time) are invoked on a dedicated callback thread. This thread is potentially distinct from any platform concept of a "main thread" or "UI thread". User callbacks should execute quickly, as a stalled callback thread can cause user-visible issues (for example, delayed completion of a sign-out request).

Properties on immutable value types are available synchronously and without blocking.