¿Qué pasa con el progreso de un jugador cuando cambia de teléfono?
Un jugador pasa seis meses en tu juego, compra el pase de temporada, llega al nivel 400 —luego se cambia de teléfono y su progreso desaparece. Los tickets de soporte se apilan, las reseñas de la tienda se ponen violentas, y la causa raíz es una decisión de diseño que tomaste el día uno sin darte cuenta. Esto es qué tiene que ser cierto para que "cambiar de teléfono" signifique "seguir jugando".
Q: ¿Por qué un ID de dispositivo no es un sistema de guardado?
Porque un ID de dispositivo —IDFA, GAID, Android ID— es un token de atribución, no una identidad. Se borra con el reset de fábrica, desaparece con el dispositivo nuevo y cada vez lo bloquean más tras avisos de privacidad (ATT, GDPR, defaults de plataforma). En cuanto un jugador cambia de hardware, ese ID se va, y si tu progreso cuelga de él, también su cuenta. La identidad tiene que venir de algo que el jugador lleva consigo: un correo, un teléfono o un SSO. Cualquier otra cosa convierte en silencio una mejora de teléfono en pérdida de datos, y el jugador culpa a tu juego, no a su sistema.
Q: ¿Cómo resuelves un conflicto de guardado en la nube sin borrar lo del jugador?
El último en escribir gana (last-write-wins) es la trampa: el jugador juega offline tres días, conecta, y su progreso local fresco es pisado por un archivo de nube viejo del martes. Los vectores de versión y los registros de operaciones (CRDT) fusionan limpio pero cuestan almacenamiento e ingeniería que quizá no necesitas. Para un juego casual, la fusión optimista por campos es el punto dulce —fusionas monedas, niveles y cosméticos como campos separados, tomando el valor más alto o más nuevo por campo—, con baja tasa de conflicto y casi nada perdido. La trampa: decide qué cuenta como verdad. Los campos de autoridad del servidor (monedas, desbloqueos) deben validarse en el servidor, no confiar en el timestamp del cliente.
Q: ¿Offline-first o cloud-first?
Offline-first: juega local y sincroniza en segundo plano —suave en mala red, pero mayor tasa de conflicto y más superficie de trampa. Cloud-first: cada acción consulta al servidor —limpio, pero inútil en cuanto se cae la conexión, fatal en mercados donde la conectividad es la excepción. La respuesta pragmática para casuales es offline-first con fusión en segundo plano más validación de servidor en los pocos campos que importan. Cambias un poco de manejo de conflictos por una experiencia que funciona en todas partes.
Q: ¿Cómo evitas que los tramposos falsifiquen una partida?
Un guardado local es un JSON de texto plano que un jugador edita con un editor o un editor de memoria —pon las monedas en nueve mil millones, desbloquea todo. La defensa empieza en el protocolo: no dejes que el cliente tenga la verdad de nada valioso. Monedas y desbloqueos firmados o guardados por el servidor, validados en cada sincronización, y detección de anomalías (un jugador que gana diez años de monedas en un día no es un bug, es una bandera). El anti-trampas no es solo un martillo de ban después; el formato de guardado mismo debe hacer inútil falsificar.
| Estrategia | Pérdida por conflicto | Costo | Para |
|---|---|---|---|
| Último en escribir gana | alta | minúsculo | datos desechables |
| Vectores de versión / CRDT | ninguna | alto | estado colaborativo |
| Fusión por campos | baja | medio | juegos casuales |
