brainCloud

Hmm, I'm guessing that this is so that you as a developer have a warning that you may be mucking with an online user's data?

Sadly, unless the user is using RTT, the system doesn't deterministically know that a user is still online.

We do however know when the user last logged in - and that is shown on the User Summary page here (see capture).

You can further get an idea if a user is still online via the User Monitoring | Logs page...

Might be interesting to see if we could query the last session for the time of the last received request... though we'd need to somehow differentiate a real session from an API Explorer session... Hmm, some food for thought.

Hi,

This is very doable in brainCloud.

Check out the Tiers design note in this knowledge-base article:
http://help.getbraincloud.com/en/articles/3344756-increasing-tournament-engagement-with-divisions-and-or-tiers

Hope that helps!

Cheers,

Paul.

Happy to help!

Hey Chris,

Turns out that there was a unique index rule that hadn't been applied to your instance. That's been fixed now - and we've confirmed that all the other indexes are up-to-date as well.

Apologies for that - you should be good to go now.

Paul.

Hi Chris,

Thanks for reporting this. It certainly shouldn't be possible - we'll get the devs to look into it asap.

Paul.

What sort of devices? Will people really sit there logged into multiple devices, and expect them all to rise in realtime?

I mean, wouldn't a user play on one device. Finish, and maybe pick up another device - and when they do, you refresh all the stats when the app loads?

I would suggest you use RTT for real-time notifications - but we actually assume that that a user would only have one logged in RTT session - so that won't work.

You could send push notifications to all of the devices. Push notifications can have data payloads - so your client app(s) can catch the updated data, or maybe the notification is just a signal to the client to request updated data... (likely more flexible).

Alternatively, I guess your option best option would be to have the devices poll every <x> minutes or so...

Honestly, the use case still seems a bit weird though - I'm probably just not understanding something

Paul.

Good questions.

1. How do you suggest we secure the increment of active usage time if clients is sending this information?
   Have the session stored in the server keep track of the time. The bridge.SetSessionCacheObject call allows you to set variables that are stored in the session - https://getbraincloud.com/apidocs/apiref/#cc-bridge-getsessioncacheobject

Maybe have a variable called "trackingTimeFromMillis" that records when tracking starts.

You could then implement an UpdateUsageTime() call that examines trackingTimeFromMillis, updates the user's device accumulated time based on the difference between now and trackingTimeFromMillis, and then resets trackingTimeFromMillis.

You could then call this script every 2 minutes or something - whatever makes sense for your app. I'd also call a variant of the script if the user exists the app... (you could have the variant script log out of the session when called via InvalidateSession call - https://getbraincloud.com/apidocs/apiref/#cc-bridge-invalidatesession).

2. What service mechanics should we use to notify all connected devices of a player with the increase of total points the player has, as well as level increases...

Hmm, I think I'll need to understand your use case better for this. Message us directly on our support channel with the details if you aren't comfortable posting it here.

3. How can we detect device disconnects? Do we need to implement polling, or is that automatically done?

brainCloud does automatically send a heartbeat to the server (to keep the session alive while the app is active) - but we don't detect disconnects or trigger api calls or events when an app exists.

All device OSes have hooks for this sort of thing though - so i'd recommend you hook into the OS's callbacks for such things, and call the UpdateUsageTime() with a disconnect parameter set to true when the user exists the app.

Hope that helps!

Paul.

Hi - apologies for the slow reply?

1. Allow one player to log into multiple devices.
   This is supported. There's a setting under Design | Core App Info | Advanced Settings to set the Maximum Concurrent Sessions Per Player. It defaults to 1, but you can set it to a higher number.

2. Allow each device to record active usage time. Granularity of 1 minute is acceptable.
   brainCloud doesn't do this automatically for you - but you could certainly record this data yourself in a user entity. You'd probably want to use your "anonyousId" as the id for the device when recording the time.

3. Total of active usage time of all devices is attributed to the player.
   I'd user a userStatistic for that. Just increment the count at the same time that you're updating the userEntity for a specific device's time. Probably use a cloud code script to better ensure that they are both updated at the same time.

4. Currency or player level increases based on total record active usage time.
   Once again, use that same cloud code script to increment currency and/or xp level.

5a. Leaderboards - by total active time of the player
Use a cumulative leaderboard to track this. That same cloud code script to increment the player's leaderboard entry.

5b. Leaderboards - aggregated total active time of multiple players as friends/guild/clan
brainCloud supports groups and group leaderboards, which could be used for this.

All of this is possible with our Lite subscription and above.

Hope that helps!

Paul.

Hi,

A bit of a clarification.

Internally, the brainCloud client is automatically retrying for you.

The timeout setting is an array - the defaults are [15, 10, 10]. This means the first timeout is 15 seconds, then 10 seconds later, and 10 seconds after that. Totally 35 seconds.

If after those 3 retries the app was unable to get a valid response, it finally sends a retry to the client.

So, a couple of things:

• 1 - don't change the defaults to make them smaller. That just hits our server harder.
• 2 - Don't blindly retry calling brainCloud if the request times out. That's already been done 3 times! Could be their having mobile networking issues. Instead - pop up a retry dialog to your client.

PS - We are considering extending this timeout a bit - because its possible to have scripts that only timeout after 60 seconds - and they aren't automatically handled without adjusting the client timeouts.

The new values we are considering are 15, 20, 35, 50 - so the full timeout becomes 2 minutes, with excalating retries.

Hope that helps!

Paul.

If the app makes a call to brainCloud that timeouts, it will generate a CLIENT_NETWORK_ERROR_TIMEOUT (90001) error in the failure callback.

_bc.EntityService.GetEntitiesByType(entityType,
    (string response, object cbObject) =>
    {
      Debug.Log("SUCCESS");
    },
    (int statusCode, int reasonCode, string statusMessage, object cbObject) =>
    {
      switch (reasonCode)
      {

        case ReasonCodes.CLIENT_NETWORK_ERROR_TIMEOUT:
          {
            // Handle the timeout 
            break;
          }
      }
    });

The brainCloud SDK will timeout after a set interval. Currently, in the 4.2 release, the default is 35 seconds, but this may be adjusted later.

You can also call SetPacketTimeouts to set a custom amount for your timeout values. But the defaults are recommended.

An example of handling a timeout error in Unity can be found in our AuthenticationErrorHandling example.