Guardado en la nube
Gamealia.data es un almacén clave-valor chico por jugador y por juego. Usalo en lugar de localStorage: acompaña a los jugadores con sesión iniciada en todos sus dispositivos. Tu juego se juega desde su propio origen (https://<tu-slug>.gamealia.app), pero las vistas previas, la revisión y los links viejos lo corren desde el origen compartido del CDN, donde el localStorage es de todos los juegos: un juego que lee claves de otros juegos falla el autotest.
Límites y dónde quedan los datos
- Los valores son JSON. La partida completa de un juego puede ocupar como máximo 1 MB por jugador, medido como los bytes UTF-8 de todas las claves juntas serializadas como un solo objeto JSON (
{"clave":valor,...}). El SDK, el portal y la API lo miden igual, así quedata.setda la misma respuesta en el mock que en el portal. - Jugadores con sesión: la partida queda en su cuenta de Gamealia, en todos sus dispositivos.
- Invitados: la partida queda en ese navegador, en el portal (no en el almacenamiento de tu juego).
- En el mock (desarrollo local): el
localStoragede este navegador, con claves que empiezan congml:local:.
Cuando el jugador inicia o cierra sesión
- Inicio de sesión: si la cuenta todavía no tiene partida guardada de este juego, la partida de invitado de este navegador se mueve a la cuenta: se escribe ahí y se borra del navegador, así otra cuenta que después inicie sesión en el mismo navegador no recibe el mismo progreso. La escritura solo ocurre si la cuenta sigue vacía (lo verifica el servidor), así que una segunda pestaña o una lectura fallida nunca pisan una partida real. Si la cuenta ya tiene una, se carga esa y la de invitado queda como estaba (nunca pisa la de la cuenta).
- Cierre de sesión: el juego vuelve a la partida de invitado de este navegador (vacía si se movió a una cuenta).
- Un
data.set,removeoclearque el juego mandó antes de que el jugador iniciara o cerrara sesión, o cambiara de cuenta, nunca se aplica a la partida del jugador nuevo: si todavía no se había ejecutado, se descarta (setresuelvefalse). - En los dos casos el SDK descarta lo que tenía en caché y dispara
userChange. Volvé a cargar la partida ahí, para no escribir el progreso del jugador anterior en la cuenta nueva:
Gamealia.user.onChange(async () => {
const r = await Gamealia.data.load();
if (r.ok) state = r.data.progress ?? newGame(); // la misma regla que al arrancar: con !r.ok, no guardes
});
El shim de CrazyGames recarga SDK.data antes de llamar a tus callbacks de addAuthListener.
Primero cargá, después guardá
await Gamealia.init();
const r = await Gamealia.data.load();
if (!r.ok) {
// No se pudo leer la partida (sin conexión, timeout): NO la pises con una partida nueva.
showRetry();
} else {
state = r.data.progress ?? newGame();
}
async function save() {
const ok = await Gamealia.data.set("progress", state); // false si no se guardó
if (!ok) showToast("No se pudo guardar");
}
data.get(key) devuelve null tanto si no hay valor como si no se pudo leer; por eso al arrancar conviene data.load().
API
| Llamada | Resultado |
|---|---|
data.load() | { ok: true, data } o { ok: false, error } |
data.get(key) | el valor o null |
data.set(key, value) | true si se guardó, false si no |
data.getAll() | todas las claves y valores ({} si falla) |
data.remove(key) | borra una clave |
data.clear() | borra toda la partida |
Consejos
- Guardá en puntos de control (fin de nivel, cambio de opciones), no en cada frame.
- Que sea chico: guardá progreso y opciones, no cachés ni archivos grandes.
- Si tenés backend propio, dejá los datos del servidor en tu servidor e identificá al jugador con un token (mirá Cuentas de jugador).
- Motores:
Gamealia.Data.*en Unity ydata_*en Godot usan el mismo almacén (Unity, Godot).