Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Welcome to PLAY (former READYgg) documentation!
The Getting Started describes the project requirements you need to meet to use PLAY SDK. The Install Dependencies describes the PLAY SDK dependencies and how to install them.
To quickly become proficient with the PLAY SDK, follow the integration steps in sequence. They will guide you through setting up and utilizing various features available on PLAY.
To review the supported features by the PLAY SDK, you can move to the modules section.
Unity integration
Unity integration
PLAY SDK requires the following software:
Unity 2020 LTS or later. Installation instructions.
It is always recommended to use a late version of Unity for bug fixes and up-to-date compatibility.
Open project settings Unity window: Edit->Project Settings...
Select Player and open the Other Settings section
For iOS tab change the Bundle Identifier
For Android tab change the Package Name
Choose Minimum API Level 23 in Project Settings->Player->Other Settings
For Android you can also change the Scripting Backend from Mono to IL2CPP. Since Unity Android Mono backend does not support arm64 which is required on Android Play Market. But to keep the development iterations faster, you can also keep Mono and only later jump to IL2CPP.
For Android, Target API Level should be 33 or higher for Google Play Store compliance.
If you are unable to find a solution in our documentation you can reach out to us directly by:
In case you use an older version of Unity you need to add the Newtonsoft Json package. You can install it by pasting following into your manifest.json file:
In the new Unity versions the Newtonsoft Json is build in to Unity. No need to install the package.
Git package repository link. The easiest way to add the READYgg SDK into your project is to use PLAY package distribution. You need simply put the package git repository links into manifest.json
file. See instructions below.
Troubleshooting : if you have error messages in Unity saying that it cannot find the git repository, make sure you have Git installed on your machine. Unity Hub needs it to import packages from Github.
Open [project_dir]/Packages/manifest.json
file in your favorite text editor
Paste following lines:
If you don't need some of the functionality, you can try to remove some modules.
The manifest.json
file after all changes should look similar to this:
Afterwards switch to Unity and wait until the packages import finishes.
Partially removing some of the modules while keeping the others has not been thoroughly tested yet by the RGN team, if you encounter any issues please
Open Package Manager Window by clicking Unity menu Window->Package Manager
Unreal Engine integration
In case you want to see our sample DEMO scene implementation you need to use our Sample package.
Import the sample package by pasting following into your manifest.json file:
After the package is imported, you can see it in Unity Package manager (Window->Package Manager):
After you import the Sample, you'll see a new folder in your Assets folder. You can open the DEMO scene from the Sample. Unity will ask you to import the TextMeshPro Essentials in case you have not done it already
The DEMO sample scene looks like this:
By default the user is logged in as a guest user. So, everything you'll do, will be stored in the cloud. At the start you can visit the Store Test and try to buy some items.
If you click on Virtual Items you can see similar UI:
Unity integration
Go on the developer dashboard and select your project.
Click on Download unity packages to download your project credentials.
Unreal integration
Go on the and select/create your project.
Open the project settings and scroll down to the Plugins category and find the “ReadyGamesNetwork”, then fill the ProjectId and ApiKey fields by values from your console project.
Unreal integration
Open your level blueprint.
All blueprints nodes for PLAY SDK you can find in special category named “ReadyGamesNetwork”.
Add two core nodes to start work with the SDK - Core /Initialize and Core /Update.
Import this file by using Unity Assets->Import Package->Custom Package... menu. After importing you should see the ReadyGamesNetwork folder in your Assets folder with all necessary settings:
Unreal integration
Introduction
To interact with the PLAY API, you will need to be authenticated. This will allow you to store and retrieve additional user data in the PLAY ecosystem.
By default, the project is configured to automatically log into a guest account. This feature is enabled in the plugin settings.
If you require more control over this process, you can disable the checkbox and manually manage guest account logins.
Unity integration
To interact with the PLAY API, you will need to be authenticated. This will allow you to store and retrieve additional user data in the PLAY ecosystem.
If the Auto Guest Login option in RGNUnityInitilizer.cs is checked, logging out from email will automatically sign you back in as guest.
Unity integration
Virtual items are game items, that can be purchased using game currency or can be rewarded as completing an Achievements. The Virtual item can also be minted an turn into NFT through the PLAY Dev Dashboard.
For example, a virtual item can be:
Racing Game: It can be different types of cars.
Puzzle game: It can be a bunch of hints pack.
Match-3 game: There can be different types of power-ups.
Shooting Game: Different types of guns, ammo etc
Virtual Items can be created using the PLAY Dev Dashboard.
IsNFT();
Return a bool to let you know if the virtual item is an NFT or not.
GetRGNCoinPrice();
Return the price in rgn-coin if the item is an NFT.
GetCustomCoinPrice(string currencyName);
Return the price based on your custom currency setup in the virtual item.
There is also a method overload for pagination requests. The pagination means you request not all items at once for the project. In this example every request contains 5 items. Each time you call the method, 5 more items will be loaded and added to the loaded item list.
It is possible the store and retrieve custom properties json string associated with virtual item. The json string should be UTF8 formatted string not longer than 100k characters.
To download virtual item image you can use following code:
To buy virtual items, please refer to the Store Module.
Unity integration
The user profile module is used to store user specific data related to his identity.
GetRGNCoinBalance();
Return the amount of rgn-coin for this user.
GetCustomCoinBalance(string currencyName);
Return the amount of your custom currency for this user.
Similar to other in-game currencies but it can only be obtained by making In-App Purchases - it cannot be earned or given as a reward to players. It is consumed to purchase NFT #virtual-items. For more details about the rgn-coin, please refer to the Currency module.
Integration Guide
Integration Guide
Virtual items are game items, that can be purchased using game currency or can be rewarded as completing an Achievements. The Virtual item can also be minted an turn into NFT through the PLAY Dev Dashboard.
For example, a virtual item can be:
Racing Game: It can be different types of cars.
Puzzle game: It can be a bunch of hints pack.
Match-3 game: There can be different types of power-ups.
Shooting Game: Different types of guns, ammo etc
Virtual Items can be added using the PLAY Dev Dashboard. In order to retrieve your list of virtual items you can use the following API.
Integration Guide
Integration Guide
Integration Guide
Unreal integration
Virtual items are game items, that can be purchased using game currency or can be rewarded as completing an Achievements. The Virtual item can also be minted an turn into NFT through the PLAY Dev Dashboard.
For example, a virtual item can be:
Racing Game: It can be different types of cars.
Puzzle game: It can be a bunch of hints pack.
Match-3 game: There can be different types of power-ups.
Shooting Game: Different types of guns, ammo etc
Virtual Items can be created using the PLAY Dev Dashboard.
Unreal integration
The user profile module is used to store user specific data related to his identity.
Similar to other in-game currencies but it can only be obtained by making In-App Purchases - it cannot be earned or given as a reward to players. It is consumed to purchase NFT #virtual-items. For more details about the rgn-coin, please refer to the Currency module.
Unreal integration
Developers have access to two different environments:
Staging: Use this environment while developing and testing. This environment will use the testing blockchain backend.
Production: Use this environment for the releases, live versions available to users.
Example.
John started integrating the READYgg SDK in his application by setting the Staging environment.
He completed and tested feature Implementation in the Staging environment.
After that, he is ready to update the version in Stores, so he set Production and created new builds for store submission. He did a smoke test and updated in Stores.
After submitting to the stores, he switched back to the Staging environment to work on new features for their upcoming release.
After setting up the above configuration data, you can switch Staging/Production environment from the Unreal plugin setting menu:
ReadyGamesNetwork->Environment Target->Staging
ReadyGamesNetwork->Environment Target->Production
Unreal integration
The users can buy Virtual Items either individually or in packs. After a virtual item is purchased it will be added to the user's inventory. You can use the to create new store offers and virtual items.
Each store offer can contain one or more virtual items to sell. Price info data is also part of the store offer. It is also possible to sell virtual items without creating store offers.
Unity integration
The users can buy Virtual Items either individually or in packs. After a virtual item is purchased it will be added to the user's inventory. You can use the to create new store offers and virtual items.
Each store offer can contain one or more virtual items to sell. Price info data is also part of the store offer. It is also possible to sell virtual items without creating store offers.
In case the virtual item contains prices information
Purchase from store offer
Get store offer
In order to purchase NFTs, there is some additional check you will need to do to make sure the user has all the requirements. Here's an example:
Unity integration
Achievements can be used to reward the player following some specific actions in your game. He can be rewarded with currencies, virtual items, progression or leaderboard score.
This function returns the completed and on going achievements for the user.
The request name can be set in the developer dashboard when creating the achievement.
If the achievement is not set to be automatically claimed when completed, you can claim it in game to show to the player the rewards he received.
If the achievement is not set to be automatically claimed when completed, you can claim it in game to show to the player the rewards he received.
The request name can be set in the developer dashboard when creating the achievement.
Unreal integration
Coming soon
Integration Guide
The AchievementsModule
allows to give the user different rewards for making progress. The first things you'll need to decide are when you want to reward the user and what should be given as a reward.
Currently, the achievements support 3 types of user rewards:
Virtual Items rewards - the virtual items are added to the user's inventory
Currency Coins rewards - the currency coins are added to the user's data. It is not possible to give the "rgn-coin" as a currency reward here.
Progression rewards - If you want to track user progress. You can use custom progression data types and store those in the user's data. When the achievement is completed and the progression rewards are given, it will increment the user's progression values accordingly. The progression values should be numbers. To retrieve the progression data you need to use the GameProgressModule:
GetUserProgressionDataAsync()
method.
You can create new achievements by using the developer dashboard or by reaching out to the PLAY team.
Integration Guide
Developers have access to two different environments:
Staging: Use this environment while developing and testing. This environment will use the testing blockchain backend.
Production: Use this environment for the releases, live versions available to users.
Example.
John started integrating the PLAY SDK in his application by setting the Staging environment.
He completed and tested feature Implementation in the Staging environment.
After that, he is ready to update the version in Stores, So he set Production and created new builds for store submission. He did a smoke test and updated in Stores.
After submitting to the stores, he switched back to the Staging environment to work on new features for their upcoming release.
After setting up the above configuration data, you can switch Staging/Production environment from the Unity menu:
ReadyGamesNetwork->Set Staging
ReadyGamesNetwork->Set Production
Unreal integration
Every project may have multiple custom currencies. For example "diamonds" and/or "cash". Aside from these typical game currencies, projects wishing to sell NFTs must integrate a specific currency. The internal name for this currency is "rgn-coin". When the "rgn-coin" is presented in the UI it can have any currency name, for example, "gems".
The "rgn-coin" can only be sold using in-app purchases. For more information, please refer to the .
Other typical currencies can be added and used in an expected manner - as rewards to the user's account, or sold for in-app purchases.
rgn-coin
(IAP required)Purchasing rgn-coin
works a bit differently, it has its own API called PurchaseRGNCoinAsync(string iapUUID)
You will need to get the transactionId and receipt when the in app purchase is completed.
Unity integration
Unity integration
Every project may have multiple custom currencies. For example "diamonds" and/or "cash". Aside from these typical game currencies, projects wishing to sell NFTs must integrate a specific currency. The internal name for this currency is "rgn-coin". When the "rgn-coin" is presented in the UI it can have any currency name, for example, "gems".
The "rgn-coin" can only be sold using in-app purchases. For more information, please refer to the Currency GDG.
Other typical currencies can be added and used in an expected manner - as rewards to the user's account, or sold for in-app purchases.
We suggest utilizing Unity's IAP Package to handle the in-app purchase process on Android and iOS.
rgn-coin
(IAP required)Purchasing rgn-coin
works a bit differently, it has its own API called PurchaseRGNCoinAsync(string iapUUID)
We recommend using the latest version of the Unity IAP plugin.
You will need to get the transactionId and receipt from the PurchaseEventArgs
when the in app purchase is completed.
Add rgn-coin to user
Get user rgn-coin
Add soft currencies to user
Get user soft currencies
Unreal Integration
Follow the link - https://github.com/readyio/rgn_unreal and clone it somewhere nearby the project directory.
Open the just pulled repository and copy the folder “Plugins” from it to the root of your project directory.
Open your project via Unreal Engine again and accept the offer to rebuild the modules.
Unreal integration
PLAY SDK requires the following software:
Unreal 5+
It is always recommended to use a late version of Unreal for bug fixes and up-to-date compatibility.
If you are unable to find a solution in our documentation you can reach out to us directly by:
Integration Guide
The LeaderboardModule is responsible for managing player scores and ranking players according to their totals. This module provides various functionalities such as setting player scores, getting leaderboard data, and fetching player entries on the leaderboard.
You can use the module to perform a variety of leaderboard-related operations:
Retrieve leaderboard data by providing a id
to the GetLeaderboardByIdAsync()
method.
The LeaderboardData contains the following fields:
LeaderboardData
id (string): Unique id of the leaderboard.
name (string): Leaderboard name. Is used also to store the localization key for the name.
description (string): Leaderboard description. Is used also to store the localization key for the description.
invertSortOrder (bool): Sorting direction. False implies that places are sorted in descending order, while true means places are sorted in ascending order.
decimalOffset (int): This parameter determines how many digits of the score integer are displayed after the decimal point. The size of the decimal part. For example, with decimalOffset: 2, the number 1234 will be displayed as 12.34.
type (string): The leaderboard type that determines the results unit. Possible values: numeric — Number, time — Time in milliseconds.
autoResettable (bool): Determines whether the leaderboard should automatically reset.
resetEveryTimeAtCron (string): A Cron expression to specify the reset period.
rewardsAtReset (LeaderboardReward[]): Rewards which will be earned at the reset period.
requiredToJoin (JoinRequirement[]): A list of requirements that must be met when a user joins a leaderboard. Joining here means adding and setting user scores. Currently, three types are supported. Please see the JoinRequirement description for more information.
createdAt (long): Date and time when the leaderboard was created. This field is automatically populated by the backend.
updatedAt (long): Date and time when the leaderboard was last time updated. This field is automatically populated by the backend.
createdBy (string): User Id who created the leaderboard. This field is automatically populated by the backend.
updatedBy (string): User Id who last time updated the leaderboard. This field is automatically populated by the backend.
LeaderboardReward
placeFrom (int): The starting position from which users will earn the reward.
placeTo (int): The ending position up to which users will earn the reward.
achievementId (string): Specifies the reward. It includes various types of rewards like virtual items rewards, currency rewards, etc, linked with a specific achievement ID.
JoinRequirement
type (string): The type of the join requirement. Currently 3 types are supported:
gamepass - The user must have a gamepass to join the leaderboard.
item_by_id - A specific virtual item identified by its ID must exist in the user's inventory.
item_by_tag - At least one virtual item in the user's inventory with the provided tag must exist.
id (string): The value for the different type criterias.
gamepass - The game pass id.
item_by_id - The virtual item id.
item_by_tag - The virtual item tag.
Retrieve leaderboard data by providing a requestName
to the GetLeaderboardByRequestNameAsync()
method.
Retrieve all leaderboard IDs defined for the current project by calling GetLeaderboardIdsAsync()
method.
Set a player's score on a leaderboard by using the SetScoreAsync()
method. This method requires leaderboardId
, score
, and optionally extraData
as parameters.
Set a player's score on a leaderboard by using the SetScoreAsync()
method with the optional parameter extraData
Fetch a player's entry from a specific leaderboard by calling GetUserEntryAsync()
. This method requires the leaderboardId
as a parameter.
To display user rankings, use the GetEntriesAsync()
method. This method takes leaderboardId
, quantityTop
, includeUser
, and quantityAroundUser
as parameters.
You can create and manage leaderboards by using the developer dashboard or by reaching out to the PLAY team.
Unity integration
The LeaderboardModule is responsible for managing player scores and ranking players according to their scores. This module provides various functionalities such as setting player score, getting leaderboard data, fetching player entries on the leaderboard and more.
Integration Guide
Integration Guide
Unity integration
PLAY SDK is divided into multiple modules. Every module has its own functionality. All modules depend on the RGNCore module. In the current version, the modules are distributed by using packages for Unity Package Manager.
RGNCore
RGNSignInEmail
RGNSignInGuest
We created an initialization script to automatically setup every module. This script can manage automatically the guest signIn and the modules initialization. To use it, simply create an empty GameObject in your starting scene and attach RGNUnityInitilizer.cs to it. With this script, you don't need to manually build the RGNCore and modules.
To access modules you can use the "I" instance provider property:
For example:
The modules are located in the RGN.Modules.[module_name] namespaces. Here you can find a full list of modules with the namespaces:
Unreal integration
Coming soon
Unreal integration
Coming soon
Unity integration
The Matchmaking Module acts as the central management system for all matchmaking procedures within the PLAY. It boasts an array of functionalities designed to facilitate the initiation, participation, voting, and termination of matches.
The primary functionality of the matchmaking module is to allow PvP matchmaking for synchronous gameplay.
Additional functionality referred to as "Voting" throughout this document allows for a matchmaking system wherein the winner is determined by votes cast by other players.
Therefor the Matchmaking module can be utilized for either PvP synchronous gameplay matches, or for the voting approach - the two styles do not have both be utilized.
type
(string): Identifies the match's type. Currently, only "default" is supported.
finishType
(string): Describes how a match concludes, either through manual input or based on score submission.
startType
(string): Outlines how a match commences, either manually or based on match filling.
maxUsers
(int): Designates the maximum number of users permitted in the matchmaking process.
isStarted
(bool): Indicates if the matchmaking process has been initiated.
votingEnabled
(bool): Defines whether voting is permitted during the matchmaking process.
oncePerUserVoting
(bool): Dictates whether a user can only vote once throughout the matchmaking process.
createdBy
(string): The identifier of the user who initiated the matchmaking process. This value is updated by the backend.
updatedBy
(string): The identifier of the user who last updated the matchmaking data. This value is updated by the backend.
createdAt
(long): The timestamp denoting the creation time of the match. This value is updated by the backend.
updatedAt
(long): The timestamp marking the most recent update of the matchmaking data. This value is updated by the backend.
participants
(list of strings): Contains user identifiers of all participants involved in the matchmaking process.
votes
(list of Vote objects): Stores the votes cast during the matchmaking process.
participantsScore
: A dictionary that maps participant identifiers to their respective scores during the matchmaking process.
participantsPayload
: A dictionary that maps participant identifiers to their respective optional payload data during the matchmaking process.
Initially, all getter methods return empty lists, implying no current match.
Here's a step-by-step overview of a match's lifecycle:
A match is created with the settings provided via CreateMatchAsync()
. By default, the user who created the match becomes a participant if participateInOnCreate
is set to true.
GetJoinOpenMatchesAsync()
returns the newly created match.
Other users join the match using ParticipateInMatchAsync()
.
Once the match fills up, it either begins automatically if matchFillBased
is selected, or manually by invoking StartMatchAsync()
.
If votingEnabled
is true, non-participating users can vote for participating users through VoteForMatchAsync()
. To retrieve matches with voting enabled, use GetVoteOpenMatchesAsync()
.
If votingEnabled
is false, participating users can submit their scores using SubmitMatchScoreAsync()
.
The match ends automatically if finishType
is set to scoreSubmitBased
once all users have submitted their scores, or it can be ended manually via FinishMatchAsync()
in case the manual
setting was submitted at the start.
The finished matches can be requested by calling the GetFinishedMatchesAsync()
method.
The backend currently supports several features that the Unity SDK does not:
participateFee
: An array of currencies. Users need to pay with these provided currencies to participate in the match.
voteFee
: An array of currencies. Users need to pay with these provided currencies to vote for other users.
createMatchAchievements
: A list of achievements with rewards given to the user who creates the match.
participateMatchAchievements
: A list of achievements with rewards given to users who participate in the match.
startMatchAchievements
: A list of achievements with rewards given to the user who starts the match.
voteForMatchAchievements
: A list of achievements with rewards given to the user who votes for other users.
winnerMatchAchievements
: A list of achievements with rewards given to users who win the match.
finishMatchAchievements
: A list of achievements with rewards given to all users who participate in the match upon its conclusion.
Should you require any of the above features or have requests for additional features, please inform the PLAY team.
The CreateMatchAsync
method within the MatchmakingModule
class is designed to asynchronously create a matchmaking match, based on the provided match configuration.
This method offers an asynchronous operation, returning a Task<MatchmakingData>
, which represents the created match.
MatchmakingData matchConfig
: The configuration for the match to be created. This cannot be null.
bool participateInOnCreate
: Optional parameter that determines whether the user participates in the match upon its creation. The default value is true.
Dictionary<string, object> participatePayload
: Optional parameter that provides additional data for user participation. The default value is null.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
ArgumentNullException
: Thrown when matchConfig
is null.
OperationCanceledException
: Thrown when the operation is cancelled via the cancellationToken
.
Here's an example usage of the CreateMatchAsync
method:
Ensure to handle the possible exceptions for a smooth user experience. Always make sure matchConfig
is not null before passing it to the method.
The ParticipateInMatchAsync
method in the MatchmakingModule
class allows a user to asynchronously participate in a matchmaking match, identified by the provided match ID.
The method performs an asynchronous operation, returning a Task<string>
that signifies the ID of the match that the user has participated in.
string matchId
: The ID of the match to participate in. This value cannot be null or empty.
Dictionary<string, object> participantPayload
: Optional parameter that provides additional data for user participation. The default value is null.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
ArgumentNullException
: Thrown when matchId
is null or empty.
OperationCanceledException
: Thrown when the operation is cancelled via the cancellationToken
.
Here's an example usage of the ParticipateInMatchAsync
method:
Be sure to handle possible exceptions to ensure a seamless user experience. Always confirm that matchId
is not null or empty before passing it to the method.
The StartMatchAsync
method in the MatchmakingModule
class allows for asynchronously starting a matchmaking match, identified by the provided match ID.
The method provides an asynchronous operation, returning a Task<string>
that represents the ID of the match that has been started.
string matchId
: The ID of the match to start. This value cannot be null or empty.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
ArgumentNullException
: Thrown when matchId
is null or empty.
OperationCanceledException
: Thrown when the operation is cancelled via the cancellationToken
.
Here's an example usage of the StartMatchAsync
method:
Always handle possible exceptions to ensure a seamless user experience. Make sure that matchId
is not null or empty before passing it to the method.
The VoteForMatchAsync
method in the MatchmakingModule
class enables the casting of a vote asynchronously for a matchmaking match, identified by the provided match ID and participant ID.
The method conducts an asynchronous operation, returning a Task<string>
that signifies the ID of the match for which the vote has been cast.
string matchId
: The ID of the match to vote for. This value cannot be null or empty.
string participantId
: The ID of the participant casting the vote. This value cannot be null or empty.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
ArgumentNullException
: Thrown when matchId
or participantId
is null or empty.
OperationCanceledException
: Thrown when the operation is cancelled via the cancellationToken
.
Here's an example usage of the VoteForMatchAsync
method:
Always handle possible exceptions to ensure a seamless user experience. Ensure both matchId
and participantId
are not null or empty before passing them to the method.
The SubmitMatchScoreAsync
method in the MatchmakingModule
class enables a user to asynchronously submit the score for a matchmaking match, identified by the provided match ID.
The method provides an asynchronous operation, returning a Task<string>
that signifies the ID of the match for which the score has been submitted.
string matchId
: The ID of the match for which the score is being submitted. This value cannot be null or empty.
long score
: The score to be submitted for the match.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
ArgumentNullException
: Thrown when matchId
is null or empty.
OperationCanceledException
: Thrown when the operation is cancelled via the cancellationToken
.
Here's an example usage of the SubmitMatchScoreAsync
method:
Always handle possible exceptions to ensure a seamless user experience. Make sure matchId
is not null or empty before passing it to the method.
The FinishMatchAsync
method in the MatchmakingModule
class allows a user to asynchronously finish a matchmaking match, identified by the provided match ID.
The method executes an asynchronous operation, returning a Task<string>
that represents the ID of the match that has been finished.
string matchId
: The ID of the match to finish. This value cannot be null or empty.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
ArgumentNullException
: Thrown when matchId
is null or empty.
OperationCanceledException
: Thrown when the operation is cancelled via the cancellationToken
.
Here's an example usage of the FinishMatchAsync
method:
Always handle possible exceptions to ensure a seamless user experience. Confirm that matchId
is not null or empty before passing it to the method.
The GetJoinOpenMatchesAsync
method in the MatchmakingModule
class allows for asynchronously retrieving a list of open matches that a user can join.
The method executes an asynchronous operation, returning a Task<List<MatchmakingData>>
that represents the list of open matches that the user can join.
int limit
: An integer indicating the maximum number of matches to retrieve.
string startAfter
: An optional parameter representing a match ID after which to start retrieving the matches. The default value is an empty string.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
Task<List<MatchmakingData>>
: A task that represents the asynchronous operation. The task result contains a list of MatchmakingData
objects, which are the open matches available for joining.
Here's an example usage of the GetJoinOpenMatchesAsync
method:
Always handle possible exceptions to ensure a seamless user experience. You can modify the limit
and startAfter
parameters to fit your application's specific needs.
The GetVoteOpenMatchesAsync
method in the MatchmakingModule
class allows for asynchronously retrieving a list of open matches that a user can vote on. Some matches may have voting enabled, allowing users to vote for match participants.
The method executes an asynchronous operation, returning a Task<List<MatchmakingData>>
that represents the list of open matches that the user can vote on.
int limit
: An integer indicating the maximum number of matches to retrieve.
string startAfter
: An optional parameter representing a match ID after which to start retrieving the matches. The default value is an empty string.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
Task<List<MatchmakingData>>
: A task that represents the asynchronous operation. The task result contains a list of MatchmakingData
objects, which are the open matches available for voting.
Here's an example usage of the GetVoteOpenMatchesAsync
method:
Always handle possible exceptions to ensure a seamless user experience. You can modify the limit
and startAfter
parameters to fit your application's specific needs.
The GetFinishedMatchesAsync
method in the MatchmakingModule
class allows for asynchronously retrieving a list of finished matches.
The method executes an asynchronous operation, returning a Task<List<MatchmakingData>>
that represents the list of finished matches.
int limit
: An integer indicating the maximum number of matches to retrieve.
string startAfter
: An optional parameter representing a match ID after which to start retrieving the matches. The default value is an empty string.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
Task<List<MatchmakingData>>
: A task that represents the asynchronous operation. The task result contains a list of MatchmakingData
objects, which are the finished matches for the current app.
Here's an example usage of the GetFinishedMatchesAsync
method:
Always handle possible exceptions to ensure a seamless user experience. You can modify the limit
and startAfter
parameters to fit your application's specific needs.
The GetFinishedMatchByIdAsync
method in the MatchmakingModule
class allows for asynchronously retrieving data of a finished match by its ID. If the match does not exist or is from another application, the method throws an exception.
The method executes an asynchronous operation, returning a Task<MatchmakingData>
that represents the data of the finished match.
string matchId
: The ID of the finished match.
CancellationToken cancellationToken
: Optional parameter to enable the cancellation of the task. The default value is an unset CancellationToken.
Task<MatchmakingData>
: A task that represents the asynchronous operation. The task result contains the MatchmakingData
of the finished match.
Here's an example usage of the GetFinishedMatchByIdAsync
method:
Always handle possible exceptions to ensure a seamless user experience. You can modify the matchId
parameter to retrieve the data of any specific finished match by its ID.
Integration guide
In order to purchase NFTs the user needs to create a crypto wallet. During wallet creation, the user must provide a password to access the wallet later. It is important to inform the user that the password must be written down or otherwise stored since neither PLAY nor developers can recover the wallet password if forgotten. The NFT virtual items are sold for "" currency.
The wallet creation is handled automatically through the OAuth form based on your game requirement. The user will be prompt to create a wallet if needed when trying to signIn.
Integration guide
Analytics events can be visualized on the .
If you are selling an NFT in your game, it is important to check the following :
Is user authenticated with a email?
Is user has a wallet?
Create wallet
Example flow for NFT purchase
List of features available to be added to the SDK
PLAY has developed and deployed on iOS and Android a variety of in-game features that are not yet a part of our SDK. We continuously add these features to the SDK as developers request them - You can review the list here and get in touch if there's a particular feature you'd like integrated into the SDK!
Rewarded Ads: Watch ads for a currency or item reward
Friends: persistent friends across the ecosystem
Online Friends Menu: Invite online friends to start a game, see who is online and what they are playing
Direct Messaging: text chat with friends
Voice Chat & Calls: Call a friend, or use voice chat during a multiplayer game
Emotes: For multiplayer gameplay
Activity Centre: surface announcements and social notifications to players
Creator Tools: allow players to create content in your game - support for any type of asset
Social Feed: Infinitely scrolling, supports trending and followed content
Post Creation Tools: Allow players to create and share posts
Unreal integration
Coming soon
Integration Guide
Unity integration
After the user purchases a Virtual Item, it is automatically added to the user's Inventory during the transaction process. It is possible also to add a virtual item to the user's inventory without going through the purchase process for non-NFT items.
The following method gets all inventory items for the currently logged in player.
Add to inventory can be use to add regular virtual items into the player inventory. NFT's cannot be added to the inventory with this function.
Benefits and Use Cases
PLAY's User Authentication Module allows a player to create a new PLAY account or log in to their existing one with email and password. Players with an account have their progress saved non-locally, which triggers several benefits both for you and your players. This feature also serves as the foundation for enabling Web3 functionality to leverage in your game.
Restore Game Progress: Players who uninstall the game can pick back up where they left off by logging in with their account. No lost progress! This functionality is doubly important if the player has made non-consumable purchases in your game.
Multiple Device Play: Players can play the game on whatever devices they have available and switch between them as desired.
Simple Sign-In: Players simply choose an email and password to create an account.
Cross-Game/Platform Friends with Web3: If your game has multiplayer or social components and as such has a friends feature - players who log in with an existing PLAY account will automatically have access to their friends. For example, Alice is friends with Bob in Game A. They log in to Game B with the same credentials they used in Game A. Bob and Alice are now in each other's friends list in Game B!
Casual, Mobile-Friendly NFTs & Crypto Wallet: PLAY's Web3 Tech Stack is enabled by the user authentication feature. For example, a player needs a crypto wallet to hold any NFTs they purchase or earn in your game. READYgg's modules allow for a super simple wallet creation flow once a player has an account. For more details and images of how the NFT flow is managed in-game see the GDG for the Store.
The below describes the general approach to adding user authentication to a game that previously had no user authentication. For titles that already have a way for players to create an account, see the next section. When it comes to triggering user authentication to prompt a player to make an account there are two primary approaches commonly seen in games today.
On Game Launch: When a player loads your game for the first time a title screen is shown with buttons prompting the player to either make an account or continue as a guest. The Guest option is often relegated to normal text while the account creation options are given larger more enticing buttons. If a player chooses to proceed as a guest the account creation options can be accessed from a menu (like settings) in-game.
On mobile platforms, this method is usually seen in titles related to extremely strong IP related to well-known brands. If you are not affiliated with such a brand it would be wise to monitor your onboarding funnel with analytics events for each step that the player will tap or click through. It is common to lose a significant portion of players at the account creation step when triggered on the launch/title screen!
Player Triggered: This represents the most common approach. When a player starts the game they are automatically playing as a guest account and must trigger account creation themselves. The game's settings menu is the most common location to allow the player to sign in and out.
A third less common approach can be seen in mobile titles with social systems integrated into their core loop: A hard currency bonus gifted to the player for creating an account. This strategy allows developers to call attention to their login options (usually still in the settings menu) and also increase the number of players that create an account.
The following describes the approach for adding PLAY account creation & login to a game or project that already has account creation. The primary difference is how onboarding players are approached in terms of flow and theming.
For example, a game that already has many registered users might opt to frame user authorization as wallet creation, instead of account creation. Likely this game would also eschew the approach of on-launch PLAY authorization - if players already have accounts using that flow would lack clarity and likely off-put players.
Benefits and Use Cases
For titles where levels or matches are played, the Game Module allows you to track player progress and give rewards when a level/match is completed.
Customizable: You are able to customize the trigger for progression (for example, after completing a level in a puzzle game, or after winning a match in a MOBA) and also enter custom rewards. Currency or XP rewards are supported by default, and you may also set up custom rewards to give, like crafting material or reward boxes.
There are some best practices to keep in mind when it comes to giving your player some rewards for completing a level or match. It's common in a variety of genres across platforms to take a moment and clearly communicate what your player has earned and, often, have them manually tap or press a button to claim their rewards. The goal here is to alleviate potential confusion for players on the type and quantity of rewards they receive - and as a result, minimize emails for support from players who incorrectly think they didn't receive a reward!
If you also give a player rewards when they level up make sure to take a similar approach! An animation is sufficient without rewards, but if rewards are given consider triggering a modal or screen to allow the player to claim them.
Guides on Player-Facing Implementation of PLAY Modules
So you've got a handle on how to integrate PLAY's SDKs into your game's code - but what about the in-game side of integration? All of PLAY's modules have been deployed live and undergone analytics-driven tuning to determine the most effective ways to implement the features in-game.
This section of PLAY's documentation is devoted to sharing these learnings and best practices for Web3 integration with you. A companion Game Design Guide is available for each of our modules that will provide you with examples of in-game UI/UX + illustrate various ways you can modify each module's in-game behaviour to suit your needs!
We hope that these Game Design Guides (to be referred to as GDG in the rest of the documentation) will help you save some time in planning your next Web3 feature integration, or spark some inspiration for the latest GDD you are working on!
Benefits and Use Cases
The Store module provides you with a multitude of ways to implement, test, and refine an optimal merchandising strategy for your game. You can list a selection of permanent store offers with single or multiple items, trigger special store offers by date and time, employ varied pricing strategies, and categorize and filter store offers using tags!
And of course, anything you can do with a regular virtual item being sold in your store can also be done with an NFT virtual item!
We also provide an additional safeguard to ensure the best experience for players while addressing the limited quantity nature of NFTs.
You may set the total quantity available for store purchase to match the number of NFTs you minted (note that this property is only available for NFT virtual items, not regular virtual items).
Once the entire supply of NFTs has been sold, the store purchase will be automatically hidden. You wouldn't want to merchandise an item to a player that they can't actually buy!
Customizable Purchase Contents: Support for selling individual items or bundles of multiple items! You have the flexibility to configure the best array of purchases and item combinations for your specific store.
Pricing Flexibility: Multiple options for optimizing your pricing strategy are available. Set the price in a single currency or a combination of currencies! Support for displaying discounts is also included, perfect to use in conjunction with a limited-time store bundle.
Store Offer Scheduling: Easily plan a schedule of limited-time offers to increase monetization. Want to create a limited-time store offer with a discount to run during the holiday weekend? Have a refreshing daily deals section? No problem - the store module has you covered.
Categorize by Tags: Titles that monetize heavily on multiple categories of virtual items inevitably require filtering support for their stores. This functionality comes with our Store Module, simply add tags to your virtual items and then use those tags to allow players to filter the store in-game.
Modifiable: If you require additional functionality not included in the SDK you may attach your own data in JSON format to virtual items or store offers!
Interoperable: Our modules also support interoperability for developers who wish to enable this functionality. An example of interoperability would be purchasing an emote in the shop for Game A and then automatically having access to that emote in Game B (the player must also use the PLAY account in both Game A and B).
As covered above, there's a lot you can do with the Store Module. The implementation examples will focus on 3 different use cases that can provide extensive value for your monetization strategies regardless of genre.
When merchandising NFTs in your game it is first and foremost important to integrate them into the game world and communicate their utility and/or rarity. We recommend theming the NFT items like any other player-facing feature or mechanic in your game. An NFT dog might be a "Rare Breed," and an NFT fashion item can be a "Limited Edition." This approach holds true even if you are a Web3 project, you'll still want to theme the NFT class of items to match the game.
However, it's also important to communicate that the items are in fact NFTs. We recommend integrating an information modal to explain NFTs to players and allow them to navigate to the PLAY player dashboard to learn more if they are so inclined. This approach in combination with theming the NFT items has been highly successful in a conversion rate of up to 42% and a 74% lift to ARPDAU.
The below image shows an example where NFT-backed virtual items are merchandised as "Limited Editions" and given a separate store entry placement from regular items.
The above image shows the tutorialization of NFTs in a social game with a casual audience.
The information modals would trigger when a player viewed the "Limited Editions" shop for the first time and could be manually triggered again by tapping a "?" button placement on that screen.
An alternative option is to simply use a manually triggered information modal - that approach may be a better fit for a less casual game and has been used in several other integrations.
The above example illustrates an NFT virtual item being merchandised in a similar fashion to a limited-time IAP - with the modification of being a hard currency purchase.
This is just one example of possible configurations, limited-time offers could also be used to set up a daily deals section within your in-game shop.
If you have a large library of virtual items that you merchandise to players in a store, you probably need filters. Even a medium amount of items could still benefit from filters, depending on your store's UI/UX.
It's important to make browsing your store simple, and even intuitive when possible, so players can just focus on picking up whatever purchases they are looking for. Any typical gamer probably has at least one example of a game they played where the shop or inventory experience had a painfully large amount of items and no easy way to categorize them (we won't name names though)!
Thankfully, you can organize your virtual items with tags and then surface those to players as categories or filters in your store. See the image below for an in-game example.
Performing inventory management can be a really fun, or a really terrible part of a game.
Make sure to carefully consider what types of categories for items would be most useful to players when they are browsing the store or viewing their inventory.
The more items you have, the more granular you might want to be.
Benefits and Use Cases
As stated in the integration tutorial, Virtual Items are any game item players collect, equip, use, etc. Virtual items may also be consumable or upgradeable. Players may purchase them, get them as rewards, or earn them from achievements - pretty much every case you may need (plus some bonus functionality!) can be handled with our Virtual Items module.
The primary distinction to keep in mind is between Virtual Items and NFT Virtual Items. This distinction becomes relevant for players when they are purchasing or acquiring NFT-Virtual Items, as they need to have a crypto wallet to store the NFT.
Easy to Use: The elusive dashboard. Not everyone has time to build a nice web interface to help you manage all that content. And you won't have to! With PLAY's Virtual Items dashboard adding new virtual items is simple to learn for any team member.
Live Content Updates: PLAY's virtual item systems let you enable or disable virtual items available for sale without releasing a new version - allowing for more granular content updates outside of version releases (or disabling a bugged item that went live!)
Simple Minting: Refreshingly easy. After creating your virtual item just head on over to the Minting Desk to select it and get minting!
Modifiable: If you require additional functionality not included in the SDK you may attach your own data in JSON format to virtual items.
There are as many options for virtual items implementation as they are game genres, so the in-game examples here will highlight consumable (referred to as "stackable" in the integration tutorial) items vs. non-consumable items.
Power-ups are employed in a variety of genres. In the below example, the player has a limited supply of 2 types of power-ups, infinite use of a basic power-up, and a new power-up that will be unlocked when they progress further.
Design-wise, the power-up that is non-consumable covers the case of a player who runs out of the more effective, consumable power-ups. Depending on your target audience and how resources are consumed, you may consider safeguards such as this to prevent a player from failing to a certain inventory state that would be difficult or tedious for them to overcome.
As for non-consumable items, anything from fashionable dresses to battle-hardened rifles goes. Virtual Items can have purely cosmetic effects like in the example below or function like a typical piece of equipment in an RPG that modifies stats and requires upgrades to reach its full potential.
Previewing is good! It's always good to let a player have a large, clear view of an item - especially when it's purely cosmetic.
For items that modify stats, make sure to be clear on the most critical information. If you intend to monetize a piece of equipment the reason why it is good should be upfront and center. Sometimes, this may work like highlighting the % stat improvement that merchandised item provides over the player's currently equipped item.
Unity integration
The MessagingModule class contains various methods that are used for subscribing and unsubscribing to topics, sending messages to a particular user (for admin users only), and receiving messages from the messaging service.
RGN.Modules.Inventory.InventoryModule.ITEM_ADDED_EVENT_TOPIC - this event is triggered when a new virtual item is added to the user's inventory by using the RGN.Modules.Inventory.InventoryModule.AddToInventoryAsync
method.
RGN.Modules.Inventory.InventoryModule.ITEM_REMOVED_EVENT_TOPIC - this event is triggered when an inventory item is removed by using the RGN.Modules.Inventory.InventoryModule.RemoveByInventoryItemIdAsync
method.
The Subscribe method is used to subscribe the message receiver to a particular topic:
void Subscribe(string topic, IMessageReceiver messageReceiver)
IMessageReceiver
interface is intended to be implemented by classes that want to receive and handle messages. The IMessageReceiver
interface defines a single method named OnMessageReceived
, which takes two parameters - a string
named topic
and an object of the type Message
.
The topic
parameter is used to identify the specific topic or channel that the message was sent on and the message
parameter contains the actual message data.
The Unsubscribe method is used to unsubscribe the message receiver from a particular topic.
Here is a code example:
The sample above shows an implementation of the IMessageReceiver
interface in a class called SomeNotificationReceiver
. This class inherits from MonoBehaviour
, which is a Unity class that allows for the creation of scripts that can be attached to game objects in a Unity scene.
The SomeNotificationReceiver
class subscribes to a specific message topic by calling the MessagingModule.I.Subscribe
method and passing in the topic string and an instance of itself as the message receiver. It also unsubscribes from the same topic in its OnDestroy
method by calling the MessagingModule.I.Unsubscribe
method.
The OnMessageReceived
method simply logs a message to the Unity console with the topic and message received. You can implement your own message handling code.
Unreal integration
Coming soon
Benefits and Use Cases
Battle/Season Passes are an integral monetization strategy today in many games, particularly multiplayer games. And for good reason - integrating a battle pass can provide dramatic lift to revenue generation, engagement, and retention.
Adding Web3 functionality on top of an already strong mechanic opens the door to creating even more innovative, fun experiences for players.
Enhanced Monetization: Introduce a new revenue stream with NFT Battle/Season Passes that provide players with benefits, instant rewards, and access to limited-time game modes and events.
Cross-Game Integration: Web3 enables passes to unlock objectives and rewards across multiple titles - unlocking powerful promotion and UA strategies.
Segment Targeting: Create customized pass bundles and trigger them for the right players!
Flexibility: Want a battle pass? Done. Want a VIP Program? Also done. Configure the pass to suit your product goals.
Supercharged NFTs: Create a pass that can be recharged or topped up - enabling more customized durations and price points for players + innovative new monetization and retention strategies.
Upgradeable: Like a real-life loyalty card, an NFT pass can gain benefits as players spend. Reward your most engaged players who participate in multiple events/seasons with perks and bonuses.
There are nearly as many versions of passes as game genres - below are some examples of how the NFT Pass module can be leveraged in particular scenarios.
Create a rechargeable NFT pass to add a highly customized subscription feature that players engage with using in-game currency.
Another possible configuration is a game pass that leverages cross-game objectives, rewards, and segmented targeting - enabling unique promotional and UA benefits for games within a studio's portfolio.
For example, a studio has two hyper-casual titles - Game A and Game B. Game B has been launched with various improved features and monetization mechanics. The studio can strategically incentivize players from Game A to install and play Game B by creating a game pass with benefits and rewards in both games.
Players in Game A would be served a game pass offer that grants rewards in Game A for trying Game B, thereby driving installs and engagement in Game B and allowing the studio to gather valuable data in Game B without any UA spend.
Cross-game promotion via game passes is also a highly proven strategy employed by the largest publishing and platform gaming companies. PLAY's NFT Pass module unlocks this functionality for studios at any level in the ecosystem!
To increase conversion for the game pass offer, segment targeting allows for multiple price points and reward configurations to be triggered for players based on their prior play and spending patterns.
Offering custom price points and bundles based on a player's preferences is a proven method of enhancing monetization & driving engagement.
PLAY's NFT Pass module allows a pass to function as a VIP/Loyalty program in addition to the core pass functionality.
VIP systems are commonly integrated into games to reward and retain spending players. As players spend, they unlock successive tiers of benefits based on the total amount they have spent in-game - incentivizing players to participate in each new season or event to improve the benefits they gain from their pass.
For example, making 5 purchases in-game could unlock a permanent 3% bonus when purchasing hard currency. Making 10 purchases could unlock access to a VIP room feature.
Another possible strategy would be rewarding players with a discounted or free pass for every 5th pass purchase (similar to a coffee shop loyalty card).
Combining typical pass mechanics with loyalty or VIP systems would increase a player's long-term investment into a game as their pass continuously increases in value the more they spend and play.
Benefits & Use Cases
PLAY's proprietary crypto wallet provides a mobile app store-compliant & casual user-friendly solution for leveraging Web3 strategies in your game.
PLAY's wallet is non-custodial, which translates to players maintaining exclusive control of their wallet. This also keeps things simple and familiar for players, no prior knowledge of Web3 is required since creation is managed simply by setting a password.
Some existing Web3 games require a wallet at the moment the game is launched, but for certain platforms or audiences, this might be a bit offputting to players looking to try a game for the first time. PLAY's Wallet Module allows you to incorporate wallet creation at the time of your choosing, whether it's at launch or day 7.
The only time the wallet is required is when players are purchasing or claiming an NFT virtual item for the first time - giving you the flexibility to determine why, how, and when to prompt players to create a wallet.
Mobile App Store Compliant: PLAY's SDK allows you to integrate Web3 on iOS and Android! Check the In-Game Implementation section for an example of a compliant NFT purchasing flow.
Casual User Friendly: It's not necessary for the player to be versed in Web3! They need only be versed in wanting to play your game or getting that awesome sword.
External Wallet Support: Players of course have the option to move their NFTs out of PLAY's proprietary wallet, with Metamask being our initially supported option. More options will be added as players or developers request!
One-Time Setup: The wallet is associated with a player's PLAY account. This means the player will only need to set up their wallet one time, in one game. After that, if they log in to another game in the ecosystem they will automatically have access to their wallet & be able to purchase or claim NFTs with no extra steps.
Developers maintain the ability to determine the best place to trigger account & wallet creation - you know your player funnels best! However, platform-based regulations (in particular on Android and iOS) mean that in order to get your submission accepted you should follow an implementation like the flow shown below.
The flow below illustrates how a player can purchase an NFT in your game on a mobile platform. If a player has an account, a wallet, and enough currency, they complete their purchase normally. Whether the player has enough currency and is logged in is handled in-game - whether or not the player has a wallet is handled in the oAUTH form.
In order for players to create a wallet in your game they'll need to set a password. This is included as part of the oAUTH flow in the web form.
For Web2 titles migrating to Web3, we do recommend keeping it simple like the above example - there were no issues with player onboarding in previous integrations that triggered account and wallet creation on NFT purchase.
Depending on your audience you may choose to implement a bit more tutorialization, see the NFT Merchandising section of the Store guide for an example.
Benefits and Use Cases
Nearly any game can benefit from an achievement system! The achievements module allows you to track progress for specific actions a player takes in your game. You can optionally add rewards for completing achievements in the form of currency or virtual items and also set specific achievements to be repeatable.
You can also optionally give NFT virtual items as rewards for achievements if desired - this would be a great way to reward engaged players who focus on completing achievements.
However, note that NFTs that are given as rewards to players may not be infused with $AURA and are instead NFTs in the traditional sense.
Therefore NFT items given as rewards are still compelling collectables for players but the health of the ecosystem token economy is preserved.
On-Chain Achievements: You can allow a player to view their achievements from all supported ecosystem titles or from specific titles in the ecosystem if you choose. Achievements are also tracked as part of the player's ecosystem profile.
Flexible: Implement the achievement types & in-game UI/UX that best suit your needs.
Support for Varied Rewards Types: If desired you may assign various reward types for achievement completion. Have players collect badges for completing achievements, or set up an achievement structure that guides and rewards players new to the game.
The types of actions you use to create your achievements are largely determined by your goals for the feature, and how involved you want players to be in the achievements system overall.
Do you want to give achievements only for the very hardest tasks that a player can do? You might consider making tough, repeatable achievements that provide a source of currency.
Looking to onboard new players? You can use achievements like a trail of breadcrumbs for players to follow as they progress through the game, gathering rewards as they discover and explore. Your achievements in that case will likely focus on giving rewards or even just XP for completing unique actions a small number of times.
Another possibility is to add a new layer of prestige for your most engaged players by leveraging achievements as a system to allow them to collect a set of NFT rewards. When creating the balancing for your achievements you can aim to create enough difficulty that players will be required to sink resources and/or spent significant effort in-game - thereby incentivizing desired behaviour as players aim to collect the complete set of NFTs!
In parallel to your creation of achievement types and balancing, you'll also need a place to host your achievements in-game, and possibly also trigger some communication to player when they get progress. See the image below for an example.
Some titles might opt to include achievements as part of the profile, others may give achievements their own distinct menu.
You'll also want to include someplace for a player to read how they might complete the achievement - in the above example, achievements look like badges so players tap to open a detail window.
You may also choose to let players know when they complete achievements, like in the example above. If doing so would disrupt your game flow in a way you'd like to avoid, you could instead add a callout to the achievements menu so the player can navigate there in their own time.
Benefits and Use Cases
The Currency In-App Purchase Module deals with any regular virtual currency you would like to sell via IAP + includes our purpose-built currency - RGN-Coins.
In order to sell NFT Virtual Items to players you must require the player to purchase those NFTs with RGN-Coins.
There are several reasons for this requirement, one of the most important is the need for payment verification to safeguard against cheaters. Payment verification for In-App Purchases is not simple to develop and the large majority of games will, when necessary, find other ways to identify cheaters and then restrict them for certain parts of the game.
RGN-Coins also allow you to leverage Web3 strategies in your game without disrupting your existing economy.
Mobile App Store Compliant: Purchasing an NFT virtual item in the same manner as a regular virtual item (with in-game currency) is compliant with iOS and Android.
Verified In-App Purchases: Since NFTs minted in the ecosystem contain $RDYX and as a result have real value, a cheater would actually be stealing money from a developer by using an in-app payment exploit for currency to spend on an NFT. With PLAY's currency IAP module, your minted NFTs will be safeguarded from any cheaters sneaking around in your game!
White-Label: RGN-Coins is our internal name for the secured currency to purchase NFTs. You may choose any player-facing name and icon design that works for your game's theme - gems, orbs, diamonds, whatever fits best!
RGN-Coins fall under the "Hard Currency" classification for in-game currencies. This means it's a premium currency that may only be acquired in large quantities via IAP. A typical hard currency will usually have a few sources for free players to acquire small amounts over time, and your game likely already has a currency that fits this description. RGN-Coins differ in that it is only acquired by IAP.
Of course, the best practices for merchandising the IAP bundles and price points remain the same as any typical currency purchase. The screen capture below illustrates 3 common merchandising strategies that you may want to incorporate in your currency shop.
Most Popular & Best Value Banners: RGN-Coins are balanced to give the best value at the most expensive purchase, so the placement would be similar to what we see above. Your in-house currency may vary! The placement of the "Most Popular" is commonly a merchandising tactic rather than a reflection of popularity. A/B testing different placements will help you determine the optimal placement to increase your monetization KPI (a safe starting point would be the first purchase that gives a discount/bonus!)
Purchase Bonus Percentage: Everybody wants to get the most out of their money. Make sure to communicate the bonus currency (as shown above) or discount percentage of your currency IAP bundles! This approach is seen in a huge variety of game stores - and it makes logical sense to communicate to players that they get a better deal for spending more money.
Purchase ThumbnailI Design: It's always nice to update the visuals alongside indicating the quantity of currency to reflect the increase. It adds visual polish and additionally can be digested at a glance compared to utilizing numbers alone.
Benefits and Use Cases
PLAY's User Profile by default supports a player username and profile photo that players can customize in-game. Players can customize the profile picture by uploading a photo from their camera roll. The username is the minimum requirement - meaning you have the freedom to implement the profile in-game in such a way that suits your game.
A player's in-game currency wallet (not to be confused with a crypto wallet) is also associated with their profile. Currency includes any existing currencies in your game + RGN-Coins - a special virtual currency obtainable only via IAP and used for purchasing NFT virtual items. See the Currency and Virtual Items guides for more details.
Persistent Player Identity: If the player has set a username and picture in a different PLAY title then it will be automatically filled in your game when they log in.
Flexible: Implement the UI/UX in-game based on your needs.
In order to enable PLAY's complete tech stack players must sign in or create their PLAY account. The most minimal in-game implementation will involve displaying the username of the player so they have visual confirmation that they have successfully signed in with the proper account.
The profile photo element is optional, and whether or not it makes sense to include both the player username and photo is largely determined by the genre of your game.
Multiplayer titles where the player does not control an avatar are the most common use case for utilizing both a customizable name and profile photo.
For example, multiplayer poker games have an emphasis on the player's identity and skill but not so much emphasis that a fully customizable avatar is required - making the profile photo a perfect choice.
If you have a single-player game where the player controls an avatar then it is entirely optional to include a customizable profile photo - players already have an identity in the form of their avatar.
Benefits and Use Cases
When players buy or earn virtual or NFT virtual items those items are added to their inventory. The Inventory module is primarily supportive - players need somewhere to stash their items!
NFT & Regular Virtual Items: A player's NFT virtual items acquired in the game are also a part of their regular inventory in addition to being in their crypto wallet. This means if the player happens to lose their crypto wallet password, they lose the ability to transfer or stake their NFT virtual items, but their ability to access and use those items in-game remains unaffected.
Upgradeable: Upgrading is a must-have feature in a wide variety of games, so our inventory supports the upgrading of non-consumable items. This means you can have upgradeable heroes, equipment, etc.
Modifiable: If you require additional functionality not included in the SDK you may attach your own data in JSON format to virtual items used in the inventory.
Flexible: Implement the UI/UX in-game based on your needs.
Interoperable: Our modules also support interoperability for developers who wish to enable this functionality. An example of interoperability would be purchasing an emote in the shop for Game A and then automatically having access to that emote in the player inventory of Game B (the player must also use the PLAY account in both Game A and B).
Inventory is yet another case where the implementation is going to depend on the genre and audience of your game.
For example, a match-3 inventory will allow players to check their unlocked and available boosters. If the player has zero of a booster there might be a button for a player to "Get More" that will take them to the store. The purpose of the inventory screen is for a player to check their current supply. See the image below for an example of a simple supply-based inventory of powerups.
Consider instead an RPG where the player can manage the various equipment on their character.
The UI/UX implementation of that inventory can vary wildly since players are making comparisons and strategic choices between multiple pairs of boots (and how they work with the rest of the equipment), not just checking if they have any boots left.
It's always a good idea to find some references in games with similar requirements to see what you think works well or doesn't work well about their inventory system. It's a great way to make some informed decisions when planning your implementation.
Unreal integration
Coming soon
Unreal integration
After the user purchases a Virtual Item, it is automatically added to the user's Inventory during the transaction process. It is possible also to add a virtual item to the user's inventory without going through the purchase process for non-NFT items.
Add to inventory can be use to add regular virtual items into the player inventory. NFT's cannot be added to the inventory with this functionality.
Benefits and Use Cases
Limited-Time Offer IAPs are an incredibly effective feature for monetization in a huge variety of game genres.
The Limited Time Offer (LTO) module allows developers to configure a variety of offer bundles that can include virtual currencies, virtual items, and NFTs.
: Define the ideal monetization strategy by testing various price points, trigger locations, durations, and item combinations.
Offer Scheduling: Set it and forget it. Months of offers can be prescheduled with individual start/end dates, price points, and item contents - all easily configured in a CSV.
Personalized Offers: PLAY's on-chain profile enables personalized LTOs based on player behaviour and preferences.
Segment Targeting: Create offers that automatically trigger for certain users, like creating a Starter Pack that only triggers for new users.
Server Control: Respond in real time to offer performance by enabling or disabling offers without the need to deploy an update.
Implementing a diverse range of offers with different price points, discounts, and durations facilitates the discovery of the most enticing offers for the player base. From bundles of discounted powerups in a match-3 game to a gun with a special skin in an FPS, the right sale at the right time can dramatically increase revenue.
PLAY's LTO Module enables the creation of all the expected offer styles needed for successful monetization, with added benefits and functionality enabled by Web3. Previous integrations have demonstrated that a limited-time offer featuring an NFT item can boost conversion rates by as much as 42%.
Create a Starter Pack by configuring an LTO to exclusively target new users.
Starter Packs represent a prevalent monetization strategy across various games and can be a major driver for climbing the top-grossing charts when integrated with established games.
It's best to not put too much time pressure on a new player to purchase the Starter Pack - the most common time frame is around 7 days.
Another approach involves offering LTOs containing rewards for multiple games.
For example, a player who frequently engages with two titles but has not yet made a purchase in either could receive an offer granting ad-free experiences or in-game currency for both titles - increasing the value proposition and likelihood of conversion.
PLAY's on-chain profile enables targeting LTOs to players across different games, based on their previous on-chain activity. This functionality facilitates triggering offers that the player is most likely to purchase, even if they have no purchase history in the game they are currently playing.
For instance, a player who previously made purchases at the $1.99 price point in Game A then transitions to Game B. Given their prior purchase history stored on-chain, an equivalently priced offer will trigger in Game B.
Additionally, LTOs can be utilized to encourage players to explore new titles aligned with their preferences.
For instance, a player in Action Game A who has been actively playing for over 14 days may be presented with an advertisement promoting Action Game B in PLAY's Dapp store, based on their preferences and retention in Action Game A.