As you may have seen in the trades, Amazon has recently announced the imminent deprecation of GameSparks to their current customers and partners.
We really like the tech and people at GameSparks and are sorry to see it go (really!). That said, we want to assure all GameSparks customers and partners that brainCloud can offer all developers (from hobbyists, startups, and big studios alike) an alternative to ensure efficient and full migration to prevent downtime for their players.
As most of you know, we launched brainCloud in 2014 and have been supporting all kinds of indies and big studios since then. We’ve also recently been working as a solution integrator in collaboration with Amazon Game Tech to assist GameSparks deprecation efforts and existing GameSparks customer migration.
brainCloud has a robust, comparable feature set that includes popular GameSparks features like Player and Game Management, Cloud Scripts, Leaderboards, Achievements, Messaging, Virtual Goods & Currencies, and Real-time features like Lobbies, Matchmaking, Notifications, and Chat.
That said, brainCloud also has advanced features not implemented in GameSparks like Custom Room & Relay Servers for real-time multiplayer, Tournaments, Blockchain Integration, Segments, Profanity Filters, Pricing and Promotion features, Playback Streams and connectivity to virtually any data collection or storage application through our Datastream service.
And of course, brainCloud supports all popular mobile and console platforms, including built-in Oculus support. We even have APIs to help migrate your users over to our back-end. And of particular interest to ex-GameSparks folks, we are happy to announce that Amazon GameLift integration will be added to brainCloud this fall!
All of this is available via a variety of licensing options that range from monthly BaaS subscriptions all the way up to private and platform licensing. All with world-class support and available professional services.
We encourage all existing GameSparks customers to check out brainCloud and let us know how we can help you migrate and grow your games on all platforms. We are here to help. Just sign up – brainCloud is free during development!
Apple is introducing comprehensive changes to iOS 14.5, iPadOS 14.5 and tvOS 14.5 that will require apps to ask users for their permission to track them across apps and websites owned by other companies.
At first glance, this seems like something that would mostly affect apps that are using user data for advertising-based monetization — but in truth, the implications are deeper than that.
For the record, we at brainCloud very much appreciate and advocate for user privacy. All user data associated with a brainCloud app is private to that app — the data is not aggregated or shared across apps or companies in any way. So if your app is using brainCloud without 3rd party authentication, you can feel confident that that data is not being shared in any way.
That said, brainCloud does support authentication-based integrations with third party providers — most importantly Facebook.
By this interpretation, just offering a classic Facebook Account login for your app — which is prety standard practice — requires you to get the user’s permission for tracking across apps and websites owned by other companies. The rationale is that your app may not be sharing the data — but Facebook itself certainly is.
Aside from Facebook’s objections to these changes (we don’t want to get into that) — Facebook has offered a recommended technical solution — they have extended their Facebook Login feature to include a new Limited Login Mode.
So — Limited Login mode seems like a pretty good solution to this problem. There is a pretty big limitation here though. If users opt for the Limited Login mode, the app will not have access to the Graph API.
For games and social apps — this is a pretty big limitation. It means that the app (and backend services like brainCloud that act on it’s behalf) will lose the ability to query Facebook for the user’s friends. This will have a huge impact on games that depend upon those sorts of social interactions for engagement and monetization.
It is therefore highly recommended that games pop-up their own informational message before Apple’s built-in pop-up, to educate the user on any features that may become unavailable as a consequence of their choice.
Another issue is that the identification information returned from the new Limited Login mode is different than with the Classic Login. This means that backend services, like brainCloud, need to implement changes to work with this new mode. The silver lining is that the underlying id of the user remains the same between the two modes — so a user who flips back and forth between the two modes can still be associated with the same back-end account — phew!
We at brainCloud are working hard to incorporate the necessary changes — and will be releasing brainCloud 4.7 with Facebook Limited Login mode before the end of March 2021.
A few more details about the changes in brainCloud 4.7:
Full Support for Facebook Limited Login mode across the authentication + identity APIs. The same user using either mode will be linked to the same underlying brainCloud profile.
brainCloud will automatically handle the loss of the Graph API for Limited Login mode users — so for example, users will simply appear to have no Facebook friends (instead of the client app having to deal with errors).
Coincidentally, brainCloud 4.7 will include new support for Steam and Playstation Network friends — so apps can extend their friend support in other areas.
brainCloud already supports self-managed Friend APIs. See AddFriends(), ListFriends(), etc.
We hope that this helps to clarify the impact of these changs to iOS 14.5, and how brainCloud can help your apps to adapt.
Executive Summary: We highly advise developers to stick with Unity 2018.X until further notice.
The symptom is that requests are being sent to brainCloud, and occasionally rejected with what brainCloud calls a signature error.
Signature errors are flagged if the content of the message that brainCloud receives doesn’t match the MD5 that has been calculated for the message. They generally mean that either the client had the wrong secret (likely a hacking attempt) or the message content has been tampered with (also likely a man-in-the-middle hacking attempt).
In this case, neither of these has occurred – rather, the message content has been corrupted somehow by Unity’s libraries (we suspect a combination of the UnityWebRequest and/or UploadHandler classes).
This doesn’t happen all-the-time… (in fact, it very rarely occurs if requests are less than 2K). But we’re seeing it happening quite often with requests that are 7K or greater in size.
After enough of these errors occur, the UnityWebRequest class is locking up – causing the brainCloud client library to stop functioning properly – requiring the app to be terminated.
Note – the good news is that brainCloud’s servers catch this issue and prevent the bad message from corrupting your data. The bad news is that a client experiencing this issue might have to retry several times to send a request – impairing client performance.
Reproducing the error
We have only been able to reproduce this error in Unity 2019.1.X(as well as 2019.2.0b5 (alpha) and 2019.3.0a5 (beta)) and only when running on iOS devices.
We do have reason to suspect that Android devices may also be impacted (but we haven’t had time to test + prove that yet). Update: We have since tested on Android and cannot reproduce the problem. So this appears to be an iOS-only issue.
Certainly, the same code running from the editor on Mac and Windows workstations seems to run just fine.
And certainly, the same brainCloud libraries (with test code) running under Unity 2018.X runs fine as well. Also, our C++/Objective-C libraries are still running fine under iOS – this issue is limited to Unity.
We have noted, as per their 2019 release notes, that Unity seems to be making significant changes to their iOS communications.
2019.1 Release notes
iOS: UnityWebRequest will use new backend based on NSURLSession. Old NSUrlConnection backed is still available (commented out in trampoline)
2019.1.4 Release notes:
iOS: Fixed larger than 2k payloads not sent by UnityWebRequest when HTTP/2 (1146305, 1152777)
For now, we recommend that developers limit their production iOS builds to Unity 2018.X or earlier.
We are constructing a limited function test app that we will submit to Unity when we report this defect. We will keep the community posted as to how that progresses.
Update – you can see the brainCloud forum post, with repro code and details, here.
In the meantime, we thought it best that our community have a heads up regarding this potential problem.
We apologize for the inconvenience and hope that through working with Unity, we can get a solution to you ASAP!
brainCloud 4 is fast approaching – and it is bringing a slew of new capabilities to the platform, including the official release of RTT (Real-time events, Chat, Messaging, Online Matchmaking, Lobbies, Presence and more!) as well as brand-new Hosting capabilities (Relay Servers and Room Servers).
As these new capabilities bring additional costs to running our infrastructure – we will be introducing revised pricing plans in coordination with brainCloud 4.
The good news is that if you aren’t using these features, nothing much changes — in fact, we’ve revised the API pricing tiers downward, so your overall costs should go down!
For the folks taking advantage of these great new capabilities, we have added new Plus plans, and have worked hard to keep the pricing reasonable and in-line with the costs to provide the service.
We are also introducing new discounted Lite plans – perfect for apps with lower usage requirements.
When 4.0 launches, the new plan lineup will look like this:
Development (Free) – access to all features, except hosting. Limited to 100 DAU, 1000 accounts. Includes 10 CCx.
Development Plus! ($5 /month) – All features, including hosting. Limited to 200 DAU, 2000 accounts. Includes 20 CCx.
Lite ($15 /month) – Core features. Includes 1M API.
Lite Plus ($25 /month) – Core features + RTT + Hosting. Includes 1M API, 50 CCx.
Standard ($30 /month) – Core features. Includes 6M API.
Standard Plus ($50 /month) – Core features + RTT + Hosting. Includes 6M API, 100 CCx.
Business ($99 /month) – Core + Enterprise features. Includes 10M API.
Business Plus ($199 /month) – All features. Includes 15M API, 250 CCx.
We are confident that we have a plan to fit every app!
As we were putting together our new set of plans, we decided to simplify and standardize the API Usage Tier Pricing.
All V4 plans use the same discounting tiers as they scale (it used to differ by plan). So no matter what plan you start with, as you get to 15M total API calls for the month, the cost per M drops to $10.00.
One side effect of this standardization is that the cost of additional usage for Business Plan customers now starts at $10.25 / M API, instead of $10.00 / M API from the old plan. To make up for this, we have bumped up the Business Plan to include 10M API for free (instead of 9M) – so it is a net win.
We have also made our API Usage pricing tiers more aggressive. In the old plans, you needed to hit 300M+ API calls to get to $9.90 / M pricing. In the new plans, we drop the price to $9.75 / M API at just 25M+ API calls.
We have accelerated the API discounting across the board, resulting in savings of 5-10% at high usage levels.
New Plus Plans
The new Plus plans make RTT and Hosting features available to apps at all usage levels.
Features available to Plus plans include:
Async Match with RTT
Relay Server Hosting
Room Server Hosting
We have worked hard to keep the incremental costs of the Plus plans low – so that as many developers as possible can integrate these great new features into their apps.
Note – Plus plans are subject to RTT Usage and Hosting Usage costs. More details in the sections that follow.
New Lite Plans
A frequent request has been for lower-cost, lower-usage plans.
We are pleased to present our new Lite and Lite Plus plans. These plans offer the all the same features as their Standard plan equivalents, but at lower 1M API usage levels.
These plans, which start at just $15 and $25 /month respectively, are great for indie developers, the development of smaller experimental apps, and even for more ambitious apps in the long-tail phase of their product lifecycle.
brainCloud’s RTT features require a nailed-up TCP or WebSocket connection for every client device. The costs to brainCloud are in maintaining connections (CCx) from our servers, and delivering the millions of real-time events to your users as they participate in chat, messaging, lobbies, etc.
To account for this utilization, we simply convert these resources to API counts.
Every RTT plan comes with a number of Concurrent Connections (CCx) that are freeper hour. For example, the Standard Plus plan includes 100 CCx. That means that a peak of 100 Users can be concurrently online without additional CCx usage fees. Assuming your average play session is 12 minutes, that might actually equate to 500 users per hour, or 12K users per day. And that’s if RTT is enabled for the full time that users are in your app. Optimize your app to only initialize RTT when you need it, and 100 CCx could equate to thousands of users per hour.
Above that, apps are charged at a rate of 10 API calls per CCx per hour. So – lets say your app was averaging double that – or 200 CCx. The additional costs would be 100 x 10 API/CCx x 24 hours x 30 days = 720,000 API counts. At ~ $10 / M API, that’s about $7.20 in usage.
The other component of RTT Usage is event delivery. RTT is great for chat and lobby operations – where one operation may fan out to dozens (or thousands) of recipients. That’s great functionality wise – but those deliveries can really add up!
The good news is that RTT is very efficient at delivering events – so we are charging at a bulk ratio of 1000:1 – that is, your app is charged just 1 API count for each 1000 events delivered!
brainCloud now supports hosting of Relay Servers and custom Room Servers. This really opens up the sort of experiences that can be accommodated in a pure brainCloud environment.
The good news is that you aren’t charged for API calls / messaging / etc to your hosted servers — even if the server is one of our Relay Servers (using our new Relay Protocol).
That said, we do of course need to pass along the cloud costs of hosting the servers, and the data transfer usage associated with it, from the cloud provider.
For pricing, brainCloud is simply marking up the hosting costs by 15%, and adding 1.5 cents per hour for managing the servers.
To help keep costs low, brainCloud will automatically spin up / down servers as required. There are a complete set of parameters that can be customized to allow Teams to fine tune the best balance between server cost and performance.
And those are the new plans!
Those are the billing changes for v 4.0.
We appreciate that brainCloud’s adherence to elastic pricing can seem a bit complicated. It is certainly more complicated than traditional per-MAU pricing. But in the great majority of cases, it is also much better value.
Our overall goal when designing our pricing models is to ensure that the pricing you are charged reflects the costs that we incur in providing the service.
We feel this approach aligns our interests. The more server resources your apps consume, the higher our costs, and the higher the price to you. But the more efficiently you can build your app, the lower our costs, and the lower the pricing for you. It’s win:win – and we are on the same side!
If you have any questions or feedback, please reach out to us via the Green Chat widget. We are always happy to hear from you!
With release 3.6.5, brainCloud is breaking away from the singletons that were previously a key aspect of our client libraries.
We thought we’d take a moment to discuss the pros and cons of the design, and explain where and why we are going a different route.
To start, lets review the purpose and design of the client library.
The goal of the client library is to simplify development of brainCloud-based applications. It does this by:
providing local implementation of brainCloud client calls (instead of forcing the client app to use Raw REST calls)
automating communications with the server (bundling of messages for efficiency, packet security, and more)
performing standard error handling
The library is actually organized into two major components:
the brainCloud Client Library – a pure, platform-independent wrapper of the brainCloud client-server protocol
the brainCloud Wrapper – simplifies aspects of the API (especially authentication) by incorporating more client-side functionality, like saving and restoring anonymousIds and profileIds.
Use of the client library is required by apps. Use of the wrapper is highly recommended, but optional. Note – originally we only had the client library. The wrapper was added later as an aid to app developers.
Delving deeper into the design, you can see that the client object maintains a list of services and internal components that work together to provide the client functionality. The wrapper on the other hand is quite simple, and merely adds an additional simplification layer to the API.
Of significance here is the use of singletons. There are two singletons in play – one for the client, and one for the wrapper. Not only are the singletons used as the reference from the client to the wrapper and/or client library objects – but they are also used for communications between BrainCloudWrapper and BrainCloudClient.
In hindsight, although our intentions were good – this usage of singletons was a mistake.
The cons (as we now see them) are:
Complicates the client code (calling the static class methods to retrieve a reference to the wrapper and or client object is more painful than using a direct global of some sort)
Complicates the documented code examples
Restricts a client to have one-and-only-one connection to the brainCloud server [ this is a crippling restriction for some use cases – couch co-op anyone? ]
And so, we are fixing this.
The changes to the new client libraries are three-fold:
BrainCloudWrapper objects now have their own reference to their associated BrainCloudClient companions
BrainCloudWrapper objects also now provide direct methods for accessing the client services: you no longer have to call wrapper → client → service → operation, instead it is simply wrapper → service → operation
The result is that instead of your client code looking like this:
So – more flexibility and clearer code? What’s the catch?
The catch is that you need to make a few changes to your client to get this goodness. For new apps it’s no big deal at all – this could be a pain for existing apps though, so we are still including a legacy singleton mode in the client libraries – but that needs to be specifically enabled.
Update: Legacy Singleton Mode has been removed from brainCloud client libraries beginning with 4.0.
Here are the steps to getting your app working using the updated libraries
Grab the latest brainCloud client library from the portal via the Team | Client Libs page.
Create an instance of BrainCloudWrapper and save it to a global accessible throughout your client app. In our documentation examples we use _bc, but it can be anything
Adjust any client code to use this new reference – try searching and replacing
“BrainCloudWrapper.Client.” → “_bc.”
“BrainCloudClient.Instance.” → “_bc.”
And that’s about it.
Note – you can optionally specify a _wrapperName to use creating the wrapper. This name will be used as a key when storing data about the session, like the anonymousId and profileId.
You only need to specify the _wrapperName if you are implementing a client with multiple concurrent connections to the brainCloud server (to help keep the session data separate). In particular, if you are updating an existing app, do not specify a profile-name – this ensures that the user does not lose their saved profile references when they upgrade to the latest version of your app!
_bc = new BrainCloudWrapper(); // optionally pass in a _wrapperName
_bc.initialize(_appId, _secret, _appVersion);
_bc = go.AddComponent<BrainCloudWrapper>();
_bc.WrapperName = "_example"; // optionally set a wrapper-name
Legacy Singleton Mode
Update: Legacy Singleton Mode has been removed from brainCloud client libraries beginning with 4.0.
Want to move to the new libraries, but change as little code as possible? No worries, we have you covered. Here’s what you do:
Grab the latest brainCloud client library from the portal via the Team | Client Libs page.
Turn on legacy singleton mode via the BrainCloudClient.EnableSingletonMode() API call. Put the call in your code right before you initialize the library.
Unity only (and only if you were using the Client static class accessor):
Adjust any calls to BrainCloudWrapper.Client.aService().anOperation() to use BrainCloudWrapper.Instance.Client.aService().anOperation() instead (Note the additional Instance step).
The following code snippet shows how to enable singleton mode in various languages:
brainCloud’s new Global Tournaments feature is an entirely new system designed to amplify player engagement in your games.
Global Tournaments are suitable for any game where competition centres around leaderboards. In fact, in their simplest version, Global Tournaments can be thought of simply as prize rules associated with a leaderboard.
But as you will see, there is actually a whole lot more to them.
When designing Global Tournaments, we had a specific set of goals in mind.
brainCloud’s Global Tournaments should:
Be easy to add to apps
Be flexible in terms of tournament schedule, phases, rules, payouts, etc.
Integrate with brainCloud’s existing reward systems
Automate key aspects of player engagement
Be manageable so that entry fees, prize amounts, etc. can change over time as you iterate
Act as building blocks for building more complex tournament types (i.e. tiered tournaments, etc.)
Work within the existing brainCloud pricing tiers
Global Tournaments support the following key features:
Duration – support for daily, weekly, and arbitrary length tournaments (up to 14 days)
Phases – support for optional announcement, enrollment, competition, buffer and award phases
Flexible Prizes – Award participants any combination of virtual currency, xp, player stats, achievements and custom data
Entry fees – Free vs. Paid Tournaments
Push Notifications – automatically send configurable push notifications at key points during the tournament
Email Integration – send custom email notifications as well
This diagram describes the main entities involved in creating a Tournament:
Leaderboards are defined in the brainCloud system by entities we call Leaderboard Configs
To create a tournament, you attach a Tournament Template to a Leaderboard Config
The Tournament Template defines the rules of a tournament – entry fees, prize rules, notification templates, etc.
The Leaderboard Config defines how scoring works (highest score, cumulative score, etc), the rotation schedule, and also the pacing of the tournament phases.
Each rotation of the leaderboard is a Leaderboard Version. All scores are stored by version in Leaderboard Entry objects.
The same tournament template may be used by multiple leaderboards. This of course creates a separate tournament per leaderboard.
A leaderboard may also attach multiple tournament templates. This is useful for cases where you want to have both free and paid versions of a tournament, that act upon the same set of scores. (rationale: better liquidity, smaller payouts)
Tournament interactions / api
The following are the key tournament interactions to understand:
Get Tournament Status – returns the status of the specified tournament, and whether the player is currently enrolled in it. If the player is not enrolled, returns details of all the tournament configs associated with the leaderboard
Join Tournament – all tournaments must be joined before you can submit scores to them. Joining a tournament involves specifying the leaderboard that anchors the tournament, and the tCode of the tournament [template] that you are joining. An entry fee will automatically be deducted from the player’s currency balance if required.
Post Tournament Score – posts an score to the tournament leaderboard. Note that you must pass in the epoch time that the game round started in, to ensure that the score is eligible. Note that there are several versions of this operation (see the API for details).
View Current Reward – returns the player’s standing in the currently active tournament, and the reward they can expect to receive if they keep this rank.
View Reward – returns the players reward for a completed tournament, and whether it has already been claimed. Will return an error if the player is not enrolled in the tournament.
Check For Events – query the brainCloud events queue to see if any Tournament Completion events have arrived
Claim Tournament Reward – claims the rewards for a completed tournament, incrementing appropriate player balances (currencies, etc.).
Tournament States are used to organize the larger tournament lifecycle. They determine when tournaments are active, processing award calculations, and available for award clams.
Tournament Phases help to micro-manage when players can join tournaments, post scores, etc. throughout the Active tournament state.
The following diagram summarizes the relationship between brainCloud tournament states and phases:
Note that brainCloud doesn’t explicitly tell you the phase it is in – instead, it gives you information as to when registration starts and ends, when play starts and ends, etc.
Events and Notifications
A key goal of brainCloud’s Global Tournaments system is to automate the tournaments interactions with players. As such, the system:
Automatically rotates and cycles through tournament states and phases as per the schedule defined
Send events to players when the tournament has completed
Optionally sends push notifications and/or emails
When a new tournament opens for registration (enrollment) – sent to previous tournament participants
When a new tournament opens for play (competition) – sent to previous and currently registered participants
When a tournament’s competition phase is close to ending – sent to current participants
When another player beats their tournament score, bumping them down a rank – sent to current participants within 10 ranks of the player who posted the score
When a tournament completes and they’re awards are ready to be claimed – sent to current participants. The system also sends an Event to the player’s event queue.
Note that you shouldn’t blindly configure all notifications – especially the email-based notifications. Some recommendations:
Obviously, do not configure both Tournament Registration start and Tournament Play start if your tournament doesn’t have an exclusive registration period, or your players will get two back-to-back notifications, and be annoyed.
Be careful about configuring Email-based notifications – we’ve included the trigger points, but for most cases we would recommend that you mostly use them to announce that a tournament is complete and that the player should come collect their prize. It’s also a handy opportunity to include info on other game offers, bonuses items to increase scores, etc.
Be aware that brainCloud does not yet support automated unsubscribes (coming soon)
Special: Scoring notifications
There are two types of designers. Designers who think that scoring notifications are cool, and those that think they could get annoying very quickly. And they are both right.
To add the engagement of scoring notifications, hopefully without overwhelming the player, we’ve added the following rules:
We’ll only send a player one scoring notification per 24-hour period
The are two additional rules that affect this:
If you post a new score, we reset the notification clock. This means that engaged players will receive more than one notification in a 24 hour period, because they’re actually responding to them.
We won’t send the player a score update until at least 30 minutes after their last posted score (i.e. you don’t want to receive a push notification immediately after exiting the game)
Bonus Features: Auto Join and Auto Reward
Global Tournaments offer an incredible way to increase engagement and monetization with your players – but what if you are just looking for a quick way to automatically add rewards to your weekly leaderboards – without code changes?
Look no further – brainCloud has two new features that allow you to automate the key portions of the tournament processing:
Auto Join – Enables players to automatically join the tournament associated with a leaderboard, simply by posting a score to it (via the standard leaderboard PostScore method). Note that this only works for leaderboards that have one-and-only-one tournament associated with them – and that tournament must be free.
Auto Claim – Causes tournament rewards to be automatically claimed by players during login. Note that the [x] Enable Tournament Auto Claim check at login compatibility flag must also be enabled on the Design | Core App Info | Advanced page of the portal
Note – although we provide the Auto Join and Auto Claim features for convenience, in most cases we would definitely recommend that you implement the full tournament API. A key benefit to tournaments is engaging with your players – getting them excited about what they can win and adding that extra flourish as they claim their prizes. Auto Join and Auto Claim hide all that – minimizing the opportunity for extra player engagement.
Features Availability and Billing Notes
Global Tournaments are available across all brainCloud subscription plans.
The basic API billing rules are in effect – 1 API count per API call, 1 API count per Push Notification, 1 API count per Email Sent
In addition, the following counts are added to offset the overheads of automated tournaments:
Awards Calculation – At the end of the tournament, 1 Bulk API Count per participant is charged to cover the CPU load of processing results and sending events to the players
PostTournamentScoreWithResults() – adds 1 Bulk API count to cover the overhead of comparing the players previous and current tournament results, and determining whether to send notifications to displaced players. As compensation, however, returns the updated tournament results (essentially GetGlobalLeaderboardView()), hopefully saving the app an API call in return.
Auto Claim – if the Auto-Claim feature is enabled, 0.5 Bulk API Counts are added to each Authentication()
On Thursday, Facebook dropped a bomb. They announced that they were shutting down Parse, the Mobile Backend-as-a-Service (MBaaS) platform that they acquired in 2013.
Parse is one of brainCloud’s competitors, and arguably the biggest and most established player in the BaaS industry. Even so, brainCloud doesn’t run up against them that much because we have a richer, more specialized featureset that works better for our customer base.
In the wake of this event, it is inevitable that people are asking “What happened?” and “How can we trust any BaaS to build our business upon”. To that end, I thought I’d put together a few thoughts.
Why was Parse shut down?
The internet is a-buzz with comments that the business must have been failing.
I don’t buy that. The business case for the Backend-as-a-Service market is very strong, and Parse had a good product for the space they were aimed at. By all accounts, they had plenty of customers and an overall strong business. So why close it?
The answer is that Parse no longer aligned with the goals of it’s parent company, Facebook.
At the time that Parse was acquired, Facebook was floundering. They had recently IPO’d, but hadn’t figured out their mobile and advertising strategy. The stock was down, revenues were down – and they made a series of acquisitions hoping to strengthen and diversify their portfolio. Parse, well positioned as a platform for enabling mobile apps, seemed like a smart play to help them build up their mobile presence. And I’d say it was.
But now, almost three years later, things have changed. Facebook has totally turned it’s ship around. It is now a juggernaught in mobile, has advertising sales through the roof, and is more focused than ever on building out its core product. In managing everything it is doing, Facebook needs to continually ask itself: “Is <x> strategic to our overall success?”
And I think that’s where Parse failed the test. Parse’s business was probably $50-$100M per year. Healthy, for sure – heck, we’d take it! But that’s just a drop in the bucket to Facebook (less than 1% of revenue!), which will net close to $20B this year. And yet, I’ll bet that division had some of Facebook’s best engineers!
And that’s what it comes down to – Facebook said as much in their blog post. They are going to “focus their resources elsewhere.” I don’t think this is the normal generic excuse that a company makes when they announce bad news – in this case, I believe that it is very literally what they are doing.
Who can you trust?
In the wake of the Parse shut-down, a lot of people will be wondering how they can put their trust in any Backend-as-a-Service. After all, a ton of people probably chose Parse specifically because it was run by Facebook – a huge, incredibly successful organization, that was guaranteed to be around for years to come.
Here is my suggestion on the evaluation criteria to consider:
Feature Set – always start with the features – there is no point in going for a solution that doesn’t meet your needs.
Organization – consider the organization that develops it. Are they a long-standing, established business, that has earned a solid reputation in the marketplace?
Funding – how is the company/product funded? Beware of purely VC-funded companies. A lot of BaaS vendors are early stage VC-funded – this makes for splashy million dollar announcements and marketing materials, but the funding comes with strings attached, in terms of “You must succeed by <x> or you will be shut down.”
Business Model – does the business model make sense? Is it easy to understand how the business would make money for the organization? If not, be wary – a “too good to be true”business model is often a sign of a last-ditch “hail mary” throw for success.
Alignment – Does the product align with the strategic goals of the parent organization. No matter how good the product, Facebook has just proven that you are in danger if a clear alignment isn’t there.
Given this critera, how does brainCloud rate?
Feature Set – we pride ourselves on our features, and the rapid pace at which they are evolving. With brainCloud (especially in comparison to a lower-level offering like Parse), you spend less time building features and more time using them. And we match each new feature with a visual tool for configuring and managing it.brainCloud goes over-and-above the classic BaaS capabilities with support for Gamification (xp, milestones, quests, achievements, leaderboards, etc.), Segmented Push Notifications, Scheduled Cloud Code, Auto Promotions, Mobile Multiplayer, Shared User Accounts, External Authentication, Server-to-Server APIs, a dynamic DataStream Architecture, and much much more.
Organization – brainCloud is built by bitHeads, a 20-year old technology software developer based in Ottawa, Canada, in conjunction with playBrains, our game development subsidiary. bitHeads has earned a reputation as one of the top software development companies in Canada, and through the years has built award-winning products for Microsoft, Sony, Blackberry, Canada Post, Samsung, E*Trade, Nortel, Mitel, and hundreds of others.
Funding – brainCloud is privately funded by bitHeads, its parent organization, with some assistance from various Canadian government programs. We are privately controlled, and thus no ultimatums.We started building brainCloud over four years ago, well before the term BaaS or MBaaS was a thing. We saw the value and opportunity in this market back then, and are determined to build the best product for it.
Business Model – we don’t give brainCloud away, but we do work to keep the cost of the service as low as possible. brainCloud is free for development (maximum 100 dau), but you pay starting at $30 / month once you go live. This minimal charge ensures that every brainCloud customer is pulling their weight and paying their share of the costs for the service. This allows us to offer lower prices than our competitors, while at the same time ensuring that bitHeads can operate brainCloud indefinitely.Contrast that with the models of some of our competitors, and ask yourselves how they can possibly be successful in the mid-to-long term? They have to charge their paid users more, and are basically betting that they will have enough high-volume customers to pay for the inevitably huge number of low-volume customers (that they subsidize for free). And some models are even crazier! These are the sorts of bets that you make when you are desperate for your next round of VC funding, or looking to be bought.
Alignment – brainCloud arose because bitHeads was constantly building custom backend solutions for our customers. And we were building them over-and-over again, with largely the same features. For online casinos. Retail networks. Telecommunications. Mobile/Social games. For twenty years.Four years ago, we finally said, wait – what if we did this once, and productized it, so that we (nor anyone else) has to keep re-inventing the wheel? And thus brainCloud was born. It started as a small, separate team working within the company to build the core server system. We released the first apps on the platform almost three years ago – before we had a design portal with which to design and manage things (configuration was CSV and JSON back then).Today the team consists of twenty-ish people within the larger bitHeads/playBrains organization, together with the support teams to make that work. All services teams at bitHeads are aligned to delivering products and services around brainCloud. The custom apps and games that we build today are built upon brainCloud – it’s our competitive advantage. And we continue to productize and evolve the platform based on the feedback of our great community of developers.There’s no fear of alignment here – bitHeads is brainCloud.
And there you have it – my take on Parse, and how bitHeads and brainCloud rate as a Backend-as-a-Server that you can trust. To our brainCloud customers today, thanks a bunch – rest assured, we are in this for the long haul.
And if this is your first exposure to brainCloud, please sign up and take a look for free. If you take a good look at our features and tools, we think you’ll realize the power of the system we’ve developed, and the passion of the folks building it.
Oh – and if you are looking to move from Parse, please check out this survey. Filling it out will help us to prioritize the tools and support processes that we’re developing to assist Parse migration.
Happy coding folks!
(PS – And for all you Parse-based folks looking to move, feel free to reach out. Our services teams would be happy to help you move over to our platform!)
This post is the first of our new series on best practices to observe before launching your app.
It’s an exciting feeling… Features are complete. Beta feedback incorporated. Final bits of polish applied. You are ready to launch.
Or are you? Are you sure that you have… Tested for every usage scenario? Every race condition? On each of thousands of device variations? Under unpredictable network conditions? Accounted for changing performance characteristics as your user base ramps?
Luckily you are using brainCloud – so you know your servers will handle the loads. But what about your client app? Your dev team is prepared to react and fix issues quickly – but how will you ensure that important updates make it to your users quickly?
Sure – the app stores support automatic software updates – but even so, it can take 3 weeks before the majority of your user base is using the new version of your app. That’s far too long if your app is crashing, corrupting data, and/or generally frustrating your users. In those 3 weeks your app’s ratings will take a huge hit.
This is why it is essential to implement Version Enforcementbefore you go live.
The good news is that brainCloud makes it easy.
brainCloud has built-in support for enforcing minimum client versions. During authentication, in addition to transmitting information about the user that is logging in, the brainCloud client library sends two key pieces of information:
platform – the type of device that the user is logging in from
gameVersion – the version of the client game or app
These parameters aren’t just informational – brainCloud’s Version Enforcement feature allows you to ensure that only users of a specified version and above can log into your application. This forces out-of-date users to upgrade their clients before proceeding.
Version Enforcement is configured via the brainCloud Portal, and works in collaboration with integration code that you add to your app.
Above – the Design | Core App Info | Platforms screen
Note – you can specify this minimum version on a per-platform basis, allowing you to accommodate staggered release schedules, different app approval processes, etc.
Integrating Version Enforcement
Integrating Version Enforcement into your app is very simple.
Follow these steps:
Set the app version in your client app. In most of the brainCloud client libraries, this is done via the BrainCloudClient.Initialize() function. In Unity, you can use the brainCloud Settings dialog.In either case, the version should be a string of format of “X.X” or “X.X.X” – for example, “1.0.0”.
Go to Design | Core App Info | Platforms, and temporarily set the minimum app version to something higher than your current app version.
Enhance the Authentication error handling of your app to catch the out-of-date error response (see the Version Enhancement section of the Authentication API page for details) – and display an appropriate message to the user. Ideally you should redirect the user to your apps store page so that he/she can trigger the update immediately. The brainCloud portal allows you to datafill the upgrade URL along with the minimum version.
Test to ensure that it works!
That’s it. Once this is in place, you will rest easier knowing that if (when) your users find problems in the field, that you’ll be able to push fixes to them in no time!