Access
Connect cross-platform accounts & identity management
Multiple Registries is a feature designed to support multiple local users logging in to the same game instance in AccelByte Cloud’s services. Having multiple registries allows game developers to create games that can support local multiplayer. It stores player information and progression for each player independently based on the account linked with the game controller.
Multiple registries are effectively containers of API clients that store logged-in player information and act as a player when calling AccelByte Cloud’s APIs.
The current SDK had limitations as it used a singleton class to represent a player, thus only allowing one account to log in at any given time within the same game instance. To overcome these limitations, we created a new class, ApiClient
to represent a player. It serves the same purpose and uses the same entry point to access AccelByte Cloud’s APIs. Game developers will need to use this new class and the multiple registries will maintain this class. The benefits of using the ApiClient
infrastructure include:
ApiClient
instances.ApiClient
is used as the entry point to create custom API classes.After you have implemented the ApiClient
class, the API calls operate in a similar manner to the previous SDK’s. These SDK changes will also impact game server implementation (which was previously mixed between client and server implementation). A new class called ServerApiClient
has therefore been created to focus on managing game server-related APIs.
Before you can implement multiple registries, you will need to install the plugins and modules of the game engine you’re using. Choose either:
NOTE
If you want to use the AccelByte Cloud Online Subsystem (OSS) in Unreal Engine, you will need these additional plugins:
You also need to configure the SDK before applying to implement multiple registries in your game. If you have never used any AccelByte Cloud SDKs, refer to one of the following guides for instructions on how to set up the configuration.
The ApiClient represents a player in your game and holds the additional APIs needed to create and send requests to the backend services.
Define each player in this class so each player can be isolated by calling GetApiClient()
, using an unique key for each player.
NOTE
For the unique key, use the following rule:
username
method in the example below:NOTE
If you are implementing multiple registries in the OSS, to differentiate each player, you need to use LocalUserNum
as a user key in every function call and set delegate.
The following diagram shows the flow you need to use an API in Unreal Engine to call the Login with Username
API.
NOTE
Your UI implementation will may vary depending on your game and the login method you choose.
Follow the steps below to create this flow:
Call Get Api Client
.
On the Return Value
, call the API you want to use. In this case, it will be the User
API.
Once this API has been successfully called, you can call the Login with Username
API.
Once the Login with Username
API has been successfully called, your setup is complete.
With the Multiple Registries feature, AccelByte Cloud supports multiplayer in a single game process. Use this guide to migrate your game from a singleton-based registry to multiple registries so your game can support multiple registries.
First of all, we assume all the APIs called from our SDK are called from singleton interfaces, which are the AccelBytePlugin
and AccelByteServerPlugin
classes.
This guide will help to transition the following APIs from singleton usage:
AccelBytePlugin
into ApiClient
.AccelByteServerPlugin
into ServerApiClient
.AccelBytePlugin.*
singleton classes in your project and replace AccelBytePlugin.
with MultiRegistry.GetApiClient().
.IMPORTANT
If you have multiple local players in the same game instance, replace AccelBytePlugin.
with MultiRegistry.GetApiClient("<INSERT_PLAYER_IDENTIFIER_HERE>").
.
AccelByteServerPlugin.*
singleton classes in your project and replace AccelByteServerPlugin.
with MultiRegistry.GetServerApiClient().
.AccelByteServerPlugin.GetDedicatedServer().LoginWithClientCredentials(...)
to var dsSession = MultiRegistry.GetServerApiClient().session; \ yield return dsSession.LoginWithClientCredentials(...);
.The game client, called FApiClient
, is a class that can be created from FMultiRegistry
.
You must prepare a key to construct the FApiClient
. The key represents the managed user, or acts as an identifier. To handle several users at the same time, you can use this method to create multiple keys.
Leave it empty to use the default user if the game has only one player in one game process/executable.
Follow the steps below to migrate FRegistry
to FMultiRegistry
:
Use Find all to locate all the FRegistry::*
classes in your project and:
FRegistry::
with FMultiRegistry::Ge
.WARNING
Do not change FRegistry::Settings
, FRegistry::Credentials
, or FRegistry::HttpRetryScheduler
.
Check that the compilation still runs after you have renamed it. If not, undo your previous changes and repeat step 1.
The steps to create the game server are similar to those for the game client in that you need to replace the registry The steps to migrate from FRegistry to FMultiRegistry are as follows:
Use Find all to locate all the FRegistry::*
singleton classes in your project and replace FRegistry::*
with FMultiRegistry::GetServerApiClient()->
.
WARNING
Do not change FRegistry::ServerSettings
.
Follow the steps below to get an ApiClient
if your game is using OSS to handle logins:
bMultipleLocalUsersEnabled
is true if there are multiple local players in a single game process.[OnlineSubsystemAccelByte]
bEnabled=true
bAutoLobbyConnectAfterLoginSuccess=false
bMultipleLocalUsersEnabled=true
LocalUserNum
that is passed.virtual bool Login(int32 LocalUserNum, const FOnlineAccountCredentials& AccountCredentials) override;
OnLoginCompleteDelegates (opens new window)
to find the login result from the identity interface.IOnlineSubsystem* SubsystemAB = IOnlineSubsystem::Get(ACCELBYTE_SUBSYSTEM);
const FOnlineIdentityAccelBytePtr IdentityPtr = StaticCastSharedPtr<FOnlineIdentityAccelByte>(SubsystemAB->GetIdentityInterface());
FApiClientPtr ApiClient = IdentityPtr->GetApiClient(in32 LocalUserNum);
LocalUserNum
that was used for login.FApiClientPtr
will be returned and can be used for various API calls by the specified user.