This article was cross-posted from the Google Developer Blog. Firebase will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Firebase even more powerful for game developers!
Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.
Google for Games Developer Summit
The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.
Here are some types of sessions to expect:
Sign up to stay informed at g.co/gamedevsummit.
Support for the game developer community
We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.
We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.
We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.
Stability is critical to your app’s success, so we’ve continued to enhance Firebase with tools to help you maintain high quality apps. This includes bringing the best of Fabric’s crash reporting tools to Firebase. Many of you have made the move from Fabric to Firebase yet still have questions like “Why do I still have ‘Fabric’ everywhere in my code?” or “Why does it feel like I am in Firebase, yet still in Fabric?”
We can now lay your questions to rest. We're excited to announce Firebase Crashlytics SDK is in Beta!
With the Firebase Crashlytics SDK, you can remove all Fabric dependencies, such as references to Fabric’s APIs in your code, giving you a much cleaner codebase.
The Firebase Crashlytics SDK is also designed to be intuitive and consistent with all other Firebase SDKs. For example, the Crashlytics SDK has consistent package names, API design, and initialization as other Firebase SDKs.
The Crashlytics SDK also supports Mac Catalyst apps, in addition to iOS, macOS, and tvOS apps. This new feature makes it easier for you to continue building apps for Apple devices.
We’ve also open-sourced the Crashlytics SDK to further increase the extensibility and transparency of our platform.
Combining analytics data and crashes helps you unlock additional insights into your app’s stability. The Firebase Crashlytics SDK works seamlessly with the Google Analytics SDK to provide features such as crash-free statistics, the Latest Release report, and Breadcrumbs. With Breadcrumbs you can see the steps a user took that led to a crash. This insight helps you reproduce and fix issues quickly. Google Analytics replaces Fabric's legacy analytics engine, Answers, so we encourage you to add Google Analytics to your apps.
Try it out!
Ready to begin developing with Firebase Crashlytics SDK? If you are upgrading from the legacy Fabric Crashlytics SDK, read our upgrade guide. Developers new to Crashlytics should begin with our getting started docs. Interested in the Crashlytics source code? View our Android and iOS repositories on GitHub.
We'd love to hear your feedback. As always, you can reach out to us through our official support page. Happy developing!
Did you play the interactive Google Doodle for the Mexican card game “Lotería” last December? If not, you can still check it out here. Lotería is a multiplayer bingo-style game that supports up to five players per room. In the digitized Doodle version, you can play with random people around the world or create a private game with your friends.
The Lotería game was developed in JavaScript primarily by one engineer over a few months, and the game's usage jumped from no players to millions literally overnight. The multiplayer component that supported it all was built entirely with the Firebase Realtime Database, which meant we could spend more time developing a great user experience, and less time worrying about infrastructure. Let's look into how we did it!
/games/{gameId}/deal = {card, time, countDown}
To detect the winner, all players listen to another database location at /games/{gameId}/winner. When a player clicks “Lotería!” and has a valid winning pattern on their board, we write their ID to that location.
/games/{gameId}/winner.
Often, there’s a close tie, so we use Reference.transaction to ensure that only the first player to call, “Lotería!” is declared the winner. We do this by making sure that /games/{gameId}/winner doesn’t already have an existing value before we write anything to that location.
Reference.transaction
/games/{gameId}/winner
To create random public games, we utilized Cloud Functions for Firebase in conjunction with the Realtime Database.
When a player selects “Random Match,” their player ID is written to the location /queue/. A Cloud Function is set up to trigger when a new entry is created, and it checks whether we have enough players to start a game. If so, it creates the game at /games/{gameId}, and writes the gameId to each player's entry, like so: /players/{playerId}/gameId = {gameId}
/queue/
/games/{gameId}
/players/{playerId}/gameId = {gameId}
Players listen to gameId on their own database entries, so they know when to transition to the gameplay screen.
gameId
Since there are a lot of players connecting simultaneously, and the Cloud Function is asynchronous, we once again used a transaction to ensure that players are removed from the queue and placed into games atomically. Making one game at a time atomically could create a bottleneck, so instead we create as many games as possible in one transaction.
Interactive Google Doodles get millions of players, so we needed to make sure that the database could handle the load. To do this, we sharded the database into multiple instances. Each instance can handle a limited amount of traffic, so we estimated how much traffic we expected to have. To do this, we wrote a load testing bot that could be run repeatedly and measured how much load this generated on a single instance. Then, we extrapolated that number to how many players we expected, which then gave us the number of instances we might need.
However, there is a downside to having too many instances: if players are spread too thinly, it might take longer for enough to connect to one instance to start a game. To solve this problem, we created an entry in the default database instance called “shards.” This was a number that could be adjusted from 1 to the maximum number of shards we created. Clients read this value and only used shards in that range. Since the Doodle was only live on the Google homepage for a short time, we updated the shards value manually through the Firebase Console, setting it lower when there was less traffic, and higher when there were spikes. Naturally, this process could be automated for a longer-running application.
Update: On Friday, February 28th, GDC 2020 organizers made the difficult decision to postpone the conference. We understand and support this decision, as we have to prioritize the health and safety of our community. Although we won’t be connecting in-person this year, we’re still excited to share the latest announcements from Firebase with you in a digital experience. Check back soon at g.co/gdc2020 for more details.
Cross-posting from the Google Developer Blog. Firebase will once again be at the Game Developers Conference to meet with you and share how we're making Firebase even more powerful for game developers!
We’re excited to see you at the upcoming Game Developers Conference (GDC) in San Francisco. Join us March 16th-20th, 2020 to learn about new products and solutions from Google that will help developers for all platforms take their game to the next level. If you can’t make it in person, sign up to keep up to date with our announcements and view the livestream.
Everything kicks off with the Google for Games Developer Summit Keynote on Monday, March 16th where product leaders from across Google will share the newest announcements for game developers. After the keynote, join in on two days of developer sessions and learn how to use Google solutions to create great games, connect with more players, and scale your business. Check out the agenda today.
Starting Wednesday, March 18th, visit our booth in the GDC Expo to experience demos and meet one-on-one with Google product experts.
If you can’t attend GDC in-person, watch the Keynote and other Developer Summit sessions via the live stream at g.co/gdc2020.
We’ll be sharing more details about what we have planned at GDC in the coming weeks — be sure to sign up to be among the first to hear the latest updates. On-site events are part of the official Game Developers Conference and require a pass to attend.
See you there!
See the full agenda
It's been over a year since we first announced Firebase In-App Messaging to help you guide app users who are actively using your app by sending them targeted and contextual messages. In-App Messaging allows you to communicate with your most valuable users and deepen their engagement by surfacing relevant offers, information, and tips as they use your app.
We have been actively working on adding more features and expanding on the capabilities of Firebase In-App messaging (such as new message layouts), and we’re excited to highlight another new feature today - the ability to auto-translate your message into multiple languages using Google Translate.
As your app user base expands into more countries and languages, it's important to make sure messages are localized for each recipient to improve engagement, and for that we have added an easy way to translate your message to many languages. To get started is simple.
1. First choose your message style and content.
2. Set your target criteria
Then in the targeting section, when you select your app, Firebase will look at your audience and determine if localizing message content would help, and provide you a helpful nudge to provide localized content:
3. Click on Localize, and you will see the following dialog.
The first section of the dialog contains the default language and strings to be localized. And if you would like to provide alternative translated messages, click on Localize next to the language you would like.
When you click on Localize, you can either enter the localized message yourself, or click on the Translate button and let Google Translate automatically do the translation for you.
4. Save your translations
Once you are done with all the translations, click on Save and continue completing the rest of the steps for your messaging campaign.
Unless you provide localized messages, all your users - irregardless of their locale - will receive the message in the default language. If you provide translations, users who’s locale matches available translations will get the localized message, and everyone else will get the default message.
We have a lot more product updates in the works for this year, and look forward to sharing them with you. If you are not already using Firebase In-App Messaging, then 2020 is the year to start. Get started today by checking out the documentation:
Getting started with Firebase In-App Messaging
