User Authentication

Benefits and Use Cases

Feature Overview

READYgg's User Authentication Module allows a player to create a new READYgg 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.

Key Benefits

1. 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.

2. Multiple Device Play: Players can play the game on whatever devices they have available and switch between them as desired.

3. Simple Sign-In: Players simply choose an email and password to create an account.

4. 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 ready 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!

5. Casual, Mobile-Friendly NFTs & Crypto Wallet: Ready'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.

In-Game Implementation: No Previous User Authentication

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.

1. 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.

Example of On Launch User Authentication - tapping "Email" opens a window for players to either login or sign up.

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!

2. 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.

In-Game Implementation: Existing Account Creation

The following describes the approach for adding READYgg 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 READYgg authorization - if players already have accounts using that flow would lack clarity and likely off-put players.