The Twinsprite Platform, currently under private beta, provides developers with the ability to manage the identity and attributes of physical objects so that they can be used as active elements inside a game. For examples, these objects could be toys, action figures or trading cards.
Although the platform primarily targets products like toys, basically any physical object can be enhanced with a digital strategy to be utilized in mobile games.
Twinsprite monitors each object, providing metrics on how an object is used to help provide insight in the behavioral patterns of users.
How it Works
The identities of all these objects are universally unique, which means that developers can effectively differentiate one object from another – even if physically they look just the same. Twinsprite call each of these unique items toyx.
All toyx have persistent attributes. For example, an action figure of a warrior can have an attribute that defines its Strength. While all of these figures will have this attribute, each toyx may have different values. This is managed within a cloud service, so the information relative to the toyx can be shared and accessed by different games via a REST API.
The company uses models which provide a master template from which developers can create big volumes of unique toyx. Each model contains a set of attributes and default values.
To demonstrate how this works, the company uses an example of building 10 000 Warrior Figures to be used with a new game. All of these toyx will have attributes that indicate their strength and health, so the model is used to include these two attributes together with a default value for each of them.
When creating the 10 000 toyx, all start out of the box with the same attributes and default values as the model. Initially they are all the same, physically and virtually. However, once each of these toyx starts evolving in different game usages, the values of these attributes will begin to be different making each toyx unique with its own history.
Some attributes can be locked. This means that although each toyx can have different values, these can only be defined in the toyx creation process. A game can read locked attributes, but not modify them. This is useful for certain type of attributes, like manufacturing date or batch code. To handle created toys updates after a model change, the models are versioned using model snapshots.
An application that needs to read and write attributes related to a specific toyx is defined as a game. The game makes use of a REST API to identify, read and update the attributes associated with an specific toyx. Each game will have a keypair, composed of an API key and a secret key, which will be provided by the Toyx Platform when the game is registered. The API key is used to determine the access rights that a specific game has over the toyx. And the secret key is used to secure the REST API through a signature.
Each toyx is an individual object which has been assigned an unique ToyxID. This ToyxID is associated with a set of attributes and values that belong only to this specific toyx. All toyx are created from an existing model, which gives to the toyx its attribute structure. If no value is provided for these attributes in the creation process, the default values registered in the model will be assigned. Specific values can be provided during the creation process which are different from the default ones. This can be useful for creating special batches of figures.
With the Warrior Figures example, a developer could create 10 000 toyx with default values, which is strength 10. Also, a special batch of 100 toyx is produced that come out of the box with an enhanced strength of 25. Then this value can be specified in the creation process for this batch.
The ToyxID is automatically generated and assigned to every toyx when it is created. This ID can be found embedded in several different mediums like QR Codes, NFC or digital image watermarking. The platform is agnostic to the medium in which the ToyxID is stored. Different mediums can be used for convenience reasons.
The ToyxID is unique for every toyx and is 216 bit long and the Toyx Header is fixed with an hexadecimal value of 3428 that never changes. This header is useful to perform a soft client-side validation. That is, if the game is expecting a ToyxID then it must start with the Toyx Header. Anything else provided by the user that doesn't start with it can be discarded. This is useful for quickly rejecting erroneous codes if the user, for example, decides to scan random QR codes instead of toyx.
A deeper server side validation is performed when the Toyx Platform has been submitted the ToyxID. The Toyx Unique Identity includes several security measures in order to maker sure that the ToyxID provided is valid, that it has not been tampered and that the game (API key) has indeed rights to access that toyx.
Click
here to request to be part of the Twinsprite private beta.