Buscando algunos pensamientos aquí. Cuando alguien inicia mi juego móvil por primera vez, preferiría que entraran primero en el juego antes de tener que preocuparse por "registrarse".
Creo que esto brinda una mejor experiencia de usuario, ya que puedes saltar instantáneamente al juego. Firebase admite cuentas anónimas y guarda el progreso en cuentas anónimas, que luego se pueden convertir en una cuenta real (por ejemplo, vincular sus cuentas de Google o Facebook a su cuenta anónima) mientras se conserva el progreso del juego.
¿Alguien tiene alguna idea sobre este enfoque o es mejor obligar a un usuario a decidir en el lanzamiento de la aplicación que elija entre crear una cuenta anónima o registrarse usando google / facebook / correo electrónico / etc.?
saludos kevin
En realidad, este es un caso de uso muy similar al que a menudo se presenta a los desarrolladores web que usan Firebase: para una aplicación de compras, a menudo dejará que un desarrollador realice el flujo de compras y finalice el pago. Cuando se completa el proceso de pago, usted "promociona" su cuenta a una cuenta completa para que no rechace a un cliente durante el flujo crítico.
Para un juego, no solo me encanta este flujo de cuenta anónimo (juega ahora, luego "actualiza" para las funciones sociales que necesites), sino que creo que puedes obtener un flujo natural realmente genial. Por ejemplo, si estuvieras haciendo tres en raya, podrías usar un enlace dinámico para invitar a tus amigos a jugar contra ti. Este enlace generalmente persistirá durante la instalación de la aplicación (iOS y Android, aunque es un poco más inestable en iOS) para que el jugador que invites pueda ingresar directamente al juego que estás jugando usando Anonymous Auth para crear una cuenta sin problemas.
Sin embargo, hay dos consideraciones que debe hacer:
Todavía está almacenando datos de usuario si empareja Realtime Database con una cuenta anónima. No soy abogado, pero si su región tiene una estricta regulación de privacidad, querrá hablar con uno.
La fusión de una cuenta anónima en un proceso de cuenta "completa" tiene algunos casos extremos no triviales. ¿Qué haces si el jugador ya tiene una cuenta completa (obviamente, tienes que fusionar los datos, pero tendrás que hacerlo a mano, ya que Firebase no tiene una forma independiente de juego para hacerlo por ti)? ¿Qué hace si un usuario diferente reclama la misma dirección de correo electrónico cuando promociona su cuenta (deberá descartar una y hay reglas para resolver cuál tiene la reclamación más fuerte para el nombre)?
2 también es un poco complicado por la arquitectura actual del SDK de autenticación de Firebase. Todos los objetos de C# son punteros a objetos de C++ bajo el capó. El "usuario actual" se vinculó de manera que hace referencia a un singleton global en el lado de C++ que representa los datos del usuario. Esto tiene el desafortunado efecto secundario de que no puede almacenar en caché los datos de un usuario en el lado de C# en el caso de que un usuario ingrese sus credenciales incorrectamente al "actualizar" una cuenta (generalmente se manifiesta al tener que volver a ingresar un nombre de usuario/contraseña y tal vez perdiendo datos almacenados en caché). Este error se está rastreando activamente (creo que es un efecto secundario de este ), pero a corto plazo solo significa que probablemente desee una buena manera de volver a cargar datos locales (suponiendo que perderá el acceso a la DB node una vez que elimine la cuenta anónima) o querrá evitar la persistencia de datos específicos del usuario antes de migrar un jugador a una cuenta "completa" (probablemente una consideración que tendría con las regulaciones de privacidad actuales de todos modos).