Reputation: 904
Seeking some thoughts here. When someone launches my mobile game for the first time, I would prefer they get into the gameplay first before having to worry about "signing up".
I think this provides for a better user experience as you can instantly jump into gameplay. Firebase supports anonymous accounts and saving progress against anonymous accounts, which can later be converted to an actual account (e.g linking their google or facebook accounts to their anonymous account) while retaining their game progress.
Does anyone have any thoughts on this approach or is it better to force a user to decide at app-launch to make a choice between creating an anonymous account or registering using google / facebook / email / etc?
Cheers Kevin
Upvotes: 2
Views: 438
Reputation: 3131
This is actually a very similar use case to what it often pitched to web developers using Firebase: For a shopping app, you'll often let a developer go through the shopping flow and finish checkout. When checkout is complete, you then "promote" their account to a full account so you don't bounce a customer out during the critical flow.
For a game, not only do I love this anonymous account flow (play now, then "upgrade" for any social features you need), but I think you can get a really cool natural flow going on. For example, if you were making tic tac toe, you could use a dynamic link to invite your friends to play against you. This link will usually persist across app installation (iOS and Android, although it's a little flakier on iOS) so the player you invite can jump right into the game you're playing using Anonymous Auth to seamlessly create an account.
There are two considerations you need to make though:
You're still storing user data if you pair Realtime Database with an anonymous account. I am not a lawyer, but if your region has strict privacy regulation you will want to talk to one.
The merging an anonymous account into a "full" account process does have some non-trivial edge cases. What do you do if the player already has a full account (obviously, you have to merge the data. But you'll have to do it by hand as there's no game-agnostic way for Firebase to do it for you)? What do you do if a different user claims the same email address when you promote your account (you'll need to throw one out, and there are rules for resolving which has the stronger claim to the name)?
2 is a little complicated also by the current architecture of the Firebase auth SDK as well. All of the C# objects are pointers to C++ objects under the hood. The "current user" was bound in a way that it references a global singleton on the C++ side representing user data. This has the unfortunate side effect that you can't cache a user data on the C# side in the case of a user entering their credentials incorrectly when "upgrading" an account (usually manifesting itself in having to re-enter a username/password and maybe losing cached data). This bug is actively being tracked (I believe it's a side-effect of this one), but in the near term it just means that you probably want a good way to either re-upload local data (assuming you'll lose access to the DB node once you drop the anonymous account) or you'll want to avoid persisting any user-specific data before migrating a player to a "full" account (probably a consideration I'd have with current privacy regulations anyway).
Upvotes: 3