Over the course of developing our latest project with brainCloud, we found ourselves having to create a lot of hacks and workarounds to the native systems provided, and wanted to provide feedback and suggestions to make said systems more robust and allow for better flexibility that would make integrating with them a lot smoother. There's a lot of great systems provided that we'd love to be able to use, but have run into restrictions that have made them unable to fit the needs for our project.

Support for User Item Rewards

One pain point our team has had throughout development is that there isn't very robust support for awarding items in Gamification settings on the design portal. XP level rewards, for instance, can award XP, currency, update user/global stats, but we can't award items. We have had to instead make a global property to hold essentially the same data as the XP Levels rewards map, but with items to award afterwards via post-hook. Even then, we have specific initial item data we want to be able to set for certain level rewards, and I don't believe there's any areas where you can do so in the portal. It would be great to be able to specify item rewards for things like Milestones, Quests, XP Level Rewards, in a designer friendly way, ideally the option to tailor the initial item data for each.

Option to Control Reward Claiming

When we were adding achievements to our game, we had to veto using the native BC achievement and milestone systems because there is no option to be able to disable automatically completing the platform-specific achievements, as well as the previously mentioned issue of not being able to award items. We wanted to be able to let users claim their achievements and daily quests on a specific menu at their own discretion, so we can play UI animations that don't really work in certain contexts. The ability to do so would definitely help us lean towards using the native system in the future, but as of now the API is a bit too opinionated.

Daily Quests / User-Relative Milestone Thresholds

Another area where we had to roll our own system was our daily quests. Milestones are almost the right fit, but there is no ability to be able to do make the completion thresholds relative to the individual user's current statistics (as far as I'm aware). For example, we can't do something like "Complete 3 levels today" with something like a user statistic due to them being absolute values. While our current system gets the job done, it would be great to be able to have the proper back-end support for adding dailies in future games.

Another small suggestion would be to include support for a "lower than" threshold, as I'm sure several games would benefit from being able to have something like a golf or race time threshold. Obviously we can workaround this by inverting the value from a ceiling value, but this feels like something most devs would at least expect support for.

Hopefully these suggestions are useful and possibly some features to be considered for the future of brainCloud. Thank you for reading.

Hey @Paul-Winterhalder

Tested and it works like a charm. Thanks again!

Currently it appears that VerifyPurchase is only compatible with the StoreKit 1's PKCS#7 receipts. With StoreKit 2 becoming more common, the receipt format is apparently shifting to using the JWS representation for verification, and is recommended by libraries like Unity Purchasing v5. So I was curious if there are plans to update VerifyPurchase via either a secondary itunes store ID or a full migration?

Any time - thanks for looking into it!

In the API docs for ScheduleRunScriptUTCv2, the description for the scriptName parameter says:

The name of the script with its absolute path to be run.

https://docs.braincloudservers.com/api/capi/script/schedulerunscriptutcv2

I've tried auto-rescheduling a script with bridge.getScriptName() given for the scriptName, which seemingly gives the correct full path, but when the scheduled job tries to run, it says it can't find the script:

Script not found: RefreshWeeklyChallengeCourse

This is a snippet of the code used to schedule the new run job:

/**
 * @returns {number} The next run date in UTC millis.
 */
function setNextScheduledRun() {
  let scriptProxy = bridge.getScriptServiceProxy();

  const now = new Date();

  const nextRunDate = new Date(Date.UTC(
    now.getUTCFullYear(),
    now.getUTCMonth(),
    now.getUTCDate(),
    2
  ));

  setToNextDayOfWeek(nextRunDate, data.dayOfWeek);


  let scriptData = data;
  let scriptName = String(bridge.getScriptName());
  let nextRunMillis = nextRunDate.getTime();

  bridge.logInfo(`Next run: ${nextRunDate.toISOString()}`);
  bridge.logInfo(`Next run millis: ${nextRunMillis}`);

  if (!data.dryRun) {
    cancelExcessJobs(scriptProxy, scriptName, nextRunDate);
  }
  
  let scheduleResponse = scriptProxy.scheduleRunScriptUTCv2(scriptName, scriptData, nextRunMillis);

  if (scheduleResponse.status !== 200) {
    bridge.logErrorJson("Failed to schedule next script run", scheduleResponse);
    return 0;
  }

  return nextRunMillis;
}

When I've manually ran the script via the API Explorer, everything works correctly and a job is scheduled. Only once I've moved the script to the root folder does it find the script and work. While this gets the job done, the issue feels like either a bug in the API or a documentation issue that could use updating.

If I'm misunderstanding something, please feel free to correct me, but I wanted to bring it up in the event that it is indeed a bug. Thank you in advance for your time.

Our team is experimenting with custom entities, saving replays of matches to be able to debug/observe gameplay. One friction point that I quickly found out though is the inability to streamline queries beyond copy/paste/editing query strings.

It'd be great if there was a way to save/manage query presets directly in the portal, with an easy way to adjust them when we want to, say, search for matches on a specific course, hole number, and where players finished within a certain timeframe, without having to tediously edit them every time. Perhaps even a feature to be able to search by referencing custom indexes created for the entities, utilizing the increased speed and efficiency that they bring.