Every application/game has users.

Each user is expected to do some activity in the application/game - for example, share a picture, place an order, play the game etc.


So, naturally, for every application, it's important to know who the user is.

Some applications require you to login using a username and password, some require you to provide your phone no.

When you do either of these, the application registers the user - that is, it keeps some record along with the identity of the user - so that it can show you the pictures you've uploaded or allow you to track an order you have placed.


Similarly, in games, it's important to know who the user is to be able to track the progress of a user.

Naturally, the importance of a profile of the user is paramount.

When you create a profile for the user, naturally, the app/game wants to store more attributes that are specific to the user - say, name of the user, some profile picture of the user (to jazz things up).


The Playblazer platform uses a combination of 2 parameters to identify the user - which makes it extremely flexible.

These are:

  1. mode
  2. user id


Given these two, the profile becomes independent of the platform/location/device from which the user is using the game.

Internally, these are treated like any other attributes.

So, you can now add multiple such attributes that can be used to identify the user - for example: (in the same (mode, user id) format)

  • (fb, fbid)
  • (google, googleid)
  • (twitter, twitterid)
  • (email, email id)
  • (username, username)

When these attributes are linked to the same user profile, you can then use any one of these pairs to identify the same profile - meaning, the user may login using his/her FB login at one point and possibly, using G+ login at some other point (provided both are linked to the same user profile).


The Playblazer platform also has the ability to store any app-specific attributes that the app can use to track anything for the given user.

This facility should ideally be used to store very small and important items and should not be used as a dump-all location to store the full inventory of the user or even the full app state.

The reason for that is the full set of attributes are returned from various APIs where it may not be necessary to return these more elaborate details (inventory, application state etc.)

The platform has more elaborate models specifically designed to handle these data more efficiently.