FAQ
Ads
Q: Is there a minimum watch time required to earn a reward, and is that enforced by the Arkadium platform?
A: No
Q: The SDK exposes a duration parameter - does this represent the ad’s total length, the minimum watch time to earn a reward, or something else?
A: This represents the total length of Ads to be shown to the user. It does not represent the minimum watch time to earn a reward.
Q: What does the int value in the ShowRewardedAd callback represent? For example, does 0 mean failure and 1 mean success?
A: Yes, 0 means failure and 1 means success.
Analytics
Q: The documentation mentions configuring analytics providers using ConfigureProvider() and a provided appId. Are these IDs specific to Arkadium’s analytics system, or can we configure third-party analytics providers like Firebase or Game Analytics as well?
A: Yes, they are specific to Arkadium's analytics. On this documentation is mentioned that:
"Every game should be assigned an appId for App Insights. Ask these from your Arkadium liaison if you don't yet have these."
Q: Is it possible to register multiple analytics providers through the SDK?
A: Yes. Currently we support AppInsights and/or a ConsoleProvider (testing purposes).
Authentication
Q: Is user login required for features like leaderboards, remote storage, or ad monetization to function properly?
A: For Leaderboards and Remote Storage yes. For Ads no.
Persistence
Q: How does RemoteStorageService handle conflict resolution when both local and remote data exist?
A: Like stated here:
"It's up to the developer to decide which storage type to use, between Local and Remote."
This means that the Developers are the ones responsible for handling what should be stored locally and remotely.
Wallet
Q: What conditions enable Gems support in a game? Is it something we configure, or is it enabled per game or platform by Arkadium?
A: It depends on different per game and/or per platform requirements, and are configured on Arkadium side. On the game side, developers need to make sure the UI/Gameplay properly adapts to both the scenario when Gems are supported, and when they are not. Check documentation for more details.
How to debug?
Our sdk is using rpc to communicate between game and Arena. To debug it, you need to enable logs and check console output.
Enable logs
import * as ArkadiumApi from '@arkadiuminc/sdk';
const sdk = await ArkadiumApi.getInstance();
sdk.debugMode(true);
After that you will see all rpc calls in console output. We have two types of rpc services: RPC publisher and RPC subscriber. RPC publisher is used to send messages to Arena/Game. RPC subscriber is used to receive messages from Arena/Game.
Let's take a look at the example:
import * as ArkadiumApi from '@arkadiuminc/sdk';
const sdk = await ArkadiumApi.getInstance();
await sdk.lifecycle.onTestReady();
We have initialized sdk and called onTestReady
method. This method is RPC publisher. It sends message to Arena/Game.
It returns promise, which will be resolved when Arena/Game will send response.
Let's take a look at the console output:
(log_origin: http://localhost:8083, log_instance_id: 0ONM3STMHlHiEqIxoIeaA) (rpc publisher) sending message:
{ module: "GameLifecycle", func: "OnTestReady", payload: [] } can send: {"isValidTarget":true,"isTargetSameAsOwnWindow":false}
We can see that game is sending message via sdk to Arena. The structure of log message is:
log_origin - the origin of window.location, where sdk instance is located.
log_instance_id - the id of rpc instance. It is used to identify which rpc instance is used to send message.
rpc publisher/subscrive - the type of rpc instance. In this case it is publisher.
sending message - custom message, which is sent to Arena/Game.
if the event in rpc is sending message, then we append info about target window, where message will be sent. The structure of target window is:
{
isValidTarget: boolean, // is target window valid
isTargetSameAsOwnWindow: boolean, // is target window the same as current window
}
This info must help you to identify, why message was not sent.
isValidTarget - Checks for target to be window like object. Generally, it is used to check if target supports postMessage method and it can be used to send message.
isTargetSameAsOwnWindow - Checks if target is the same as current window. If the game is inside iframe, it should be false. Probably the target was set incorrectly.
For each send message you must see the response message:
(log_origin: http://localhost:3511, log_instance_id: sarO0qvXgqPbNa0K9cwsY) (rpc subscriber) send a response for GameLifecycle_OnTestReady_60_1703172714823_0.007 , can send: {"isValidTarget":true,"isTargetSameAsOwnWindow":false}
(log_origin: http://localhost:8083, log_instance_id: 0ONM3STMHlHiEqIxoIeaA) (rpc publisher) got response:
{ module: "GameLifecycle", func: "OnTestReady", payload: [] } from: http://localhost:8083
Here we can see that Arena has sent response to our message. It has different log_origin and log_instance_id, because it is Arena and it is different instance. Then we see that Game got a respsone from Arena.
You must see this log message at last.
(log_origin: http://localhost:8083, log_instance_id: 0ONM3STMHlHiEqIxoIeaA) (rpc publisher) got a response: GameLifecycle_OnTestReady_60_1703172714823_0.007 has a callback: true
It means that sdk has received response from Arena and it has called callback function.
If it has callback function, it means that promise will be resolved, if not it will be stuck forever.
If function return undefined, promise also must be resolved.
So if your promise is stuck, you need to check console output, probably something wrong with target you have passed to sdk.
Summary:
If your game is inside iframe.
- Enable logs
- check if target is valid and it is not the same as current window.
- check if for each request there is a response.
- check if there is only one log_instance_id got a response.
- check your game in sandbox, it make some kind of self check and light indicators in UI with green if everything is ok. Both indicators must be green.