Cerrar una pestaña del navegador no debería borrar cuatro horas de progreso. Parece obvio, pero muchos juegos de navegador tratan el al...

Cerrar una pestaña del navegador no debería borrar cuatro horas de progreso. Parece obvio, pero muchos juegos de navegador tratan el localStorage como algo secundario. Un jugador alcanza una puntuación alta, ajusta su configuración, regresa al día siguiente y no encuentra nada. Peor aún, regresan después de un parche y el juego lanza un error porque el archivo de guardado en su máquina ya no coincide con el código que acabas de lanzar. Construir un shooter de estilo survivor en Phaser 4 significa lidiar con oleadas constantes de enemigos, pero la verdadera amenaza a largo plazo son tus propias actualizaciones futuras.

La mayoría de los desarrolladores construyen su primer sistema de guardado tomando un objeto, pasándolo por JSON.stringify y volcándolo en localStorage. Al cargar, lo parsean y se lo devuelven al juego sin procesar. Eso funciona el primer día. Se rompe en el momento en que añades un nuevo ajuste, una nueva bandera de desbloqueo o una tercera capa de configuración anidada. Si un jugador que regresa tiene un archivo de guardado antiguo al que le falta la propiedad vignette, y tu nuevo código espera que exista, obtendrás un undefined donde esperabas un booleano. Multiplica eso por una docena de funciones nuevas y tendrás una pesadilla de depuración que afectará primero a tus jugadores más leales.

Empieza con un contrato, no con un objeto en bruto

Antes de tocar siquiera el localStorage, define un esquema de guardado por defecto en tu código base. Piensa en ello como un contrato que cada archivo de guardado debe respetar, ya sea que se haya creado hace cinco minutos o hace cinco meses. Un punto de partida claro podría verse así:

const defaultSave = {
  highScore: 0,
  settings: {
    screenShake: true,
    vignette: true
  }
};

Este objeto reside en tu código fuente. Cuando el juego arranca, siempre tienes esta estructura disponible. Te proporciona una base. También te obliga a pensar en la estructura antes de serializar nada. Si te saltas este paso y simplemente guardas cualquier objeto de estado que te resulte conveniente en ese momento, terminarás con claves inconsistentes, campos faltantes y fallos silenciosos cuando los guardados antiguos se desincronicen con tus expectativas.

Carga defensiva con Try/Catch

El localStorage no es una base de datos. Es un armario de cadenas de texto en el navegador, y cualquier cosa puede terminar allí. El usuario podría haber editado manualmente un valor, una operación de escritura a medio terminar podría haberse interrumpido, o una extensión del navegador podría haber volcado basura en la clave que reclamaste. Cuando extraes esa cadena y se la pasas a JSON.parse, un solo carácter corrupto lanza una excepción crítica. En un juego de Phaser, ese error no controlado puede congelar tu secuencia de arranque o devolver al jugador a una pantalla en blanco.

Envuelve siempre tu lógica de lectura y análisis en un bloque try/catch. En caso de fallo, recurre a tu esquema por defecto. El objetivo es simple: si el archivo de guardado no se puede leer, trata al jugador como un usuario nuevo en lugar de colapsar toda la sesión. Este único hábito separa los proyectos de aficionados de las versiones de nivel de producción. No cuesta casi nada implementarlo y te ahorra informes de errores misteriosos que son imposibles de reproducir.

Fusiona los datos antiguos con los valores por defecto

Un análisis exitoso no significa que estés a salvo. Nunca reemplaces tu objeto por defecto por completo con el resultado del parseo. Es posible que ese viejo archivo de guardado no contenga tus ajustes más recientes. Podría almacenar screenShake pero no vignette. Si la lógica de tu juego asume que vignette existe porque se incluyó en la última actualización, volverás a estar persiguiendo errores de undefined.

En su lugar, fusiona los datos cargados con tus valores por defecto. Usa Object.assign para superponer los valores guardados sobre el esquema base. Los valores por defecto rellenan automáticamente cada hueco faltante. Las nuevas propiedades que añadiste en la versión dos obtienen sus valores iniciales del objeto por defecto. Las propiedades existentes que el jugador realmente cambió se sobrescriben con sus preferencias guardadas. Todos ganan. El jugador que regresa mantiene su puntuación alta y el juego obtiene acceso al nuevo interruptor que añadiste ayer sin explotar.

Ten en cuenta que Object.assign realiza una fusión superficial (shallow merge). Si tu objeto de configuración se vuelve profundamente anidado con el tiempo, es posible que necesites manejar esos objetos internos con un poco más de cuidado. Aun así, el principio se mantiene: los datos del jugador deben decorar tus valores por defecto, no reemplazarlos por completo.

Versiona tus claves

Los navegadores no eliminan automáticamente las entradas antiguas del localStorage. Si cambias tu estructura de datos drásticamente, necesitas una forma limpia de abandonar el formato antiguo. Nombra tu clave de almacenamiento con un sufijo de versión. bitSurvivorsSave_v1 es explícito. Te indica exactamente qué esquema escribió ese archivo. Más adelante, cuando reestructures la progresión o añadas un sistema de inventario completo, pasa a bitSurvivorsSave_v2.

Esto te ofrece dos beneficios prácticos. Primero, nunca procesarás accidentalmente un blob de la v1 con la lógica de la v2. Segundo, puedes escribir código de migración si así lo decides. Al arrancar, comprueba si existe la v1. Si existe y la v2 no, migra los datos antiguos a la nueva estructura, escríbelos en la nueva clave y continúa. Si no quieres migrar, al menos la clave antigua permanecerá inofensiva en el almacenamiento mientras tu nuevo código la ignora. De cualquier manera, el versionado evita la corrupción silenciosa.

Haz que el guardado sea invisible

La persistencia debería sentirse como respirar. El jugador nunca debería tener que pensar en ello. No añadas un botón de "Aplicar" en tu menú de ajustes. Los botones de aplicar crean fricción y entrenan a los usuarios para que se preocupen por si sus elecciones realmente se guardaron. También invitan a la pérdida de datos cuando un jugador cambia tres opciones, olvida pulsar Aplicar y cierra la pestaña.

Guarda en el momento en que ocurra la interacción. Cuando el jugador marque una casilla para desactivar el temblor de pantalla, llama a tu función de escritura inmediatamente. Cuando la partida termine y se sume la puntuación final, escribe la nueva puntuación máxima antes de que la pantalla de game over termine de animarse. El guardado basado en eventos mantiene tu arquitectura predecible porque el guardado siempre vive justo al lado de la acción que cambió los datos. Nunca tendrás que buscar una función de procesamiento por lotes centralizada ni preocuparte por estados obsoletos.

Este enfoque también simplifica tu modelo mental. Sabes exactamente dónde ocurre la persistencia: en el callback que gestiona el cambio (toggle) y en la función que gestiona la muerte. No hay escrituras misteriosas dispersas por todo el código base.

Crea un botón de reinicio para ti mismo

Corromperás tus propios archivos de guardado durante el desarrollo. Escribirás datos erróneos, probarás casos límite y necesitarás volver a un estado limpio rápidamente. Crea un botón de reinicio en un menú de depuración o mediante una combinación de teclas oculta. Haz que ese botón de reinicio haga dos cosas en este orden exacto: reinicia tu estado en memoria al esquema por defecto y, acto seguido, llama a la misma función de guardado que escribe en el local storage.

Si solo limpias la variable local y te saltas el paso de escritura, no habrás logrado nada. La próxima vez que se actualice la página, los datos antiguos volverán a extraerse del navegador y resucitarán. Un reinicio que olvida persistir es el tipo de error que te hace perder una tarde entera. Domina la secuencia una vez y tu ciclo de pruebas se mantendrá rápido durante el resto del proyecto.

La conclusión real

Guardar no es una funcionalidad que añades al final. Es la infraestructura que define si tu juego se siente duradero y respetuoso con el tiempo del jugador. Un shooter de supervivencia en Phaser 4 vive o muere según las partidas repetidas. Si la pestaña del navegador es una pistola cargada apuntando al progreso del jugador, acabará dejando de volver. Escribe un esquema, defiéndete de los datos erróneos, fusiona en lugar de reemplazar, versiona tus claves y guarda en cada evento significativo. Tu "yo" del futuro, y cada jugador que regrese tras tu próxima actualización, te lo agradecerán.