Migración de esquemas de partidas guardadas y escrituras recuperables

Un guardado es una interfaz de larga vida

Un archivo de guardado puede sobrevivir al código que lo generó. Renombrar un campo, cambiar unidades o dividir una estructura de inventario modifica esa interfaz aunque el análisis del archivo siga funcionando. Conviene diseñar la persistencia en torno a un modelo de datos documentado, una versión de esquema y una vía de recuperación, en lugar de serializar objetos vivos arbitrarios.

Formato no es compatibilidad

La guía de guardado de Godot ilustra la serialización explícita del estado del juego y las limitaciones de los tipos de JSON. [1] Protocol Buffers documenta sus reglas de compatibilidad, entre ellas conservar la identidad de los números de campo y reservar los números de los campos eliminados. [2] Un formato de serialización ayuda a representar los datos, pero el significado propio del juego, los valores por defecto, las migraciones y los rangos de versiones admitidos siguen siendo responsabilidad del diseño.

Ejemplo práctico

Un guardado ilustrativo de versión 1 contiene coins: 125. La versión 2 sustituye ese campo por wallet: {gold: 125}. La versión 3 añade difficulty y usa normal solo al migrar un guardado anterior que carece del campo.

Implementa las transformaciones 1 → 2 y 2 → 3 sobre los datos ya decodificados. Tras el primer paso, comprueba que la moneda sigue siendo 125; tras el segundo, comprueba el valor por defecto y que se conserva todo el progreso no relacionado. Actualiza la versión registrada solo cuando cada transformación haya terminado con éxito. Un guardado de versión 3 no debe recibir ninguna recompensa adicional por el simple hecho de cargarse de nuevo.

Si un guardado de versión 5 es más reciente de lo que este cargador admite, consérvalo e informa de la incompatibilidad. Adivinar su significado y sobrescribirlo con la versión 3 convertiría un problema temporal de compatibilidad en una pérdida de datos.

Flujo de migración y restauración

Mantén fixtures inmutables para cada esquema histórico admitido, incluidos los campos opcionales ausentes y los valores límite. Antes de reemplazar el mundo activo, valida los tipos de datos, los rangos, los identificadores estables de los objetos, los recursos necesarios y las referencias cruzadas. Siempre que sea viable, construye el estado restaurado de forma aislada y actívalo una vez validado.

Separa la migración de esquema de la reasignación de contenido: un objeto eliminado del juego requiere una política documentada de sustitución o compensación, no basta con renombrar un campo. Haz que los errores indiquen qué hacer y conserva el guardado utilizable anterior hasta que se verifique el nuevo.

Límites de confirmación y de fallo

En los guardados respaldados por SQLite, confirma los datos y la versión del esquema en una sola transacción; su documentación sobre la confirmación atómica explica tanto el mecanismo como las suposiciones sobre el almacenamiento. [3] En los guardados en archivo, prepara un reemplazo completo y usa las operaciones de reemplazo atómico y de durabilidad que ofrezca la plataforma. Renombrar el archivo, por sí solo, no garantiza en todos los casos la integridad ante un corte de energía.

Prueba las escrituras interrumpidas, el almacenamiento lleno, las entradas corruptas y los fallos de migración. Una suma de comprobación (checksum) puede detectar corrupción accidental, pero no establece que la semántica del juego sea válida. Define de forma explícita cómo se elige la copia de seguridad y cómo se recupera, y no informes nunca de éxito antes de que la operación de persistencia elegida se haya completado correctamente.

Fuentes

[1] Saving games — documentación de Godot Engine.

[2] Proto3 language guide — documentación de Protocol Buffers.

[3] Atomic commit — desarrolladores de SQLite.