-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Simple, you already try to fish for more users (customers), so why not increase the size of the pool (ocean)? Provide Parental Freedom™ in your game and see even more parents happy to buy. Better still, get more parents recommending your game to even more parents.
Essentially, if you don't choose to add Allow2, then you are must be happy with less users and lower sales.
Oh, and by the way, it's completely free.
Allow2 has designed to remove all the complexity to allow you to focus on making a great game.
This section provides the basic steps to integrate and leverage the Allow2 Parental Freedom™ SDK for Unity.
Before using any functions, set the device token (create one with (your free Allow2 Developer Account)[https://developer.allow2.com]). You should do this early in the program lifecycle, probably in your base setup or root view initialisation code.
// change this to your specific device token from your Allow2 developer account.
Allow2.DeviceToken = "B0hNax6VCFi9vphu";
Somewhere in settings, provide the option to "Pair" the device/game with Allow2. This is usually only be done once, and can only be released by the parent account once paired (so if already paired - show "Paired with Allow2" and don't bother allowing the user to get to the pairing screen any more.
The pairing details are persisted in the player prefs, but there is a check that will lock up the game if a child tries to clear the player prefs, until the parent releases the device/app and re-pairs it.
You can easily check if paired with Allow2:
if (Allow2.IsPaired) { ... }
If not paired, then you can provide an interface to allow pairing. The first way to let users pair Allow2 is to provide a username(email) and a password field and have a "Pair" button. (Optionally also provide a "name" field - see below)
On clicking the "Pair" button:
- Disable the pairing button and show an indeterminate progress indicator.
- Call the "Pair" method on the Allow2 Library (and supply a callback for completion notification).
Allow2.Pair(
this, // Allow2 needs a MonoBehaviour
"user supplied allow2 account email address", // the user account
"user supplied password", // their password
"A Name", // the name of this device or app
delegate (string err, Allow2CheckResult result)
{
remove_spinner(); // stop the activity indicator
if (err != null) {
// something went wrong, the pairing did not work for the reason in the string.
show_error_to_user(err);
reenable_pair_button();
clear_password_field_and_set_focus(); // essentially up to you what makes sense for your app
return;
}
});
NOTE: Allow2 also has options to connect via OAuth and QRCode, these functions will be implemented shortly in the Allow2Unity SDK
The Name is actually something for the parents to uniquely identify this particular game or device. A good option is to default this to the name off the device (if available) or just the name of your app, but it's even better to provide a field for users to change the name as well. They can do it on the Allow2 Portal, but it's nice to let them name it prior to pairing to avoid the extra step.
The alternate way for parents to Pair with Allow2 is to show them a QRCode and then wait for a pairing event. Although this is more convenient to the end user, you should always present both options, typically by showing the QRCode first, with an option to instead log in manually, and if they selects that option, switching to the username/password option as in (2a) above.
In any case, the "Name" field (if you provide one) should remain visible in both options.
There are 2 steps to allow for QRCode pairing.
- Generate a QRCode and display it.
Simply drop a texture image placeholder of a good size for a QRCode on your interface. Then, on displaying the interface, call the static Allow2.getQR method to retrieve a QRCode, you should also call the same static method to regenerate the QRCode if the user changes the name field (as it is embedded in the QR Code). We recommend doing that by using a "debounce" method, such as waiting for half a second to see if they have finished typing.
Allow2.GetQR(this, "Bob's iPhone", delegate (string err, Texture qrCode)
{
Debug.Log("qrcode error: " + err);
if (qrCode != null) {
// display the qrCode in the texture image component
}
});
- Start the pairing process
Allow2 pairs by polling the Allow2 platform to see if this QRCode has been "seen". You start this by using Allow2.StartPairing static method. You usually do this the moment you present the pairing interface. This will continually poll the Allow2 platform and repeatedly call your callback to either tell you what is going wrong, or that it's been paired successfully.
Allow2.StartPairing(
this, // Allow2 needs a MonoBehaviour
delegate (err, notUsed) {
if (err != null) {
// if there is an error, more information will be in the err string
// you should most likely present some feedback here to the user to let them
// know something is going wrong, otherwise they will think your game is broken
ShowAnError(err);
// just return after displaying the error, this routine will be called again repeatedly
// until we have paired, or you stop the pairing process.
}
// if there is no error, we have successfully paired
pairingView.dismiss(); // you can dismiss your pairing interface here
// and maybe show a success message.
});
- Stop the pairing process
If the user dismisses your pairing interface, they may do so without pairing, in this case you should call the static method Allow2.StopPairing. This stops the polling. If you don't call this, then the polling will basically run all the time, with no real benefit.
Allow2.StopPairing();
Note: if you do get successfully paired (using either method) the sdk will automatically stop the pairing process for you.
Once Allow2 is Paired, it returns a list of children names, IDs and PINs (for unlocking).
There are multiple ways to handle child assignment to the device or account.
- The user can "Assign" the device to a child. So, perhaps the game is installed on the childs computer, or on their phone or otherwise. Then, when the game is running, we know it's that child, so you don't need to supply the child id or do any authentication. This occurs on the web portal end, and it overrides any child ID sent when checking for access (below).
- The child can "Log In" on the game (use this method if, say, the game has no real "account" per se, and multiple children could be using it, like on a shared device or console with no "user" accounts, like a shared iPad for example). In this case, you can use the Allow2.children attribute to get the list of children, show a selection list and allow kids to select their name, and use their pin to "log in" before playing the game.
- The parent can associate a child id with the child account. Use this method on the setup screen and have the parent choose which child id to use for that account. This should persist the child id in a solid place (such as in your server profile for that child), as it would be relatively easy for a child to "disconnect" the child id.
Here is the real part of the whole system we have been working towards.
So there are 2 methods of checking/logging usage.
If you are doing just a simple check for access BEFORE allowing access (just to say IF it can be used right now, for instance), then use the Check method with log=false:
Allow2.Check(
this,
<child id>,
new int[] { <array of activities to check> },
delegate (string err, Allow2CheckResult result)
{
if (result != null)
{
Debug.Log("Allowed: " + result.IsAllowed);
if (!result.IsAllowed)
{
Debug.Log(result.Explanation);
}
}
},
false);
But if you want to log usage, change the log flag to "true".
You can call this as often as you want, it locally (and remotely) rate-limits the calls and manages caching, etc.
But for continuous usage, you are better off using "StartChecking" and "StopChecking" - you can call these once and the sdk handles just checking and notifying you each time. So call it once the player starts the game and leave it alone.
The arguments for StartChecking are identical to the adhoc "check" call. But your callback will be called repeatedly until you use StopChecking to stop (such as when the game is back on the menus).
When you get an update, the "result" is actually a fairly comprehensive JSON structure with some convenience methods. You can interrogate it to find out a lot of information about the current state, how much allowance is left, when things are likely to shut off, why they no longer allowed, etc.
You can use the feedback in the callback to make integrated experiences for your players. For example, when time is running out, or before you allow a player to start a new level, you can work out if they may have enough time and warn them with an NPC running up and telling them to "take shelter" or something.
You can also use the returned limitations to "gracefully" push the child to finish up, with increased "urgency". You see, common approaches just turn off the internet or the game like a switch, an abrupt and volatile approach. If you want to REALLY have your customers (parents) rave about your game and give a big kick to your sales, then make the game NICELY stop. Give heaps of warning and time to save, make it "fun" to be pwned by a super monster that appears if you repeatedly ignore the warnings, etc.
Use this new power to really embed and gamify the experience.
A major power of the Allow2 Parental Freedom™ Platform is the ability to allow players to make requests from within your app or game.
To do this, use the interface to show what type of day it is, what bans are in place and a message field. Let the player choose what to ask for and then use Allow2.Request to send it to the parent on behalf of the player.
Copyright Allow2 2019