Los jugadores vuelven para el siguiente episodio con rutas elegidas, escenas desbloqueadas y tiempo invertido. Trata la compatibilidad de las partidas guardadas como una función que debes mantener en cada lanzamiento. Cambiar los nombres de los elementos del estado, eliminar escenas o modificar objetos serializados puede inutilizar partidas guardadas antiguas aunque una partida nueva funcione correctamente.
Los sistemas de guardado difieren entre motores. Consulta la documentación de la versión exacta de tu motor y registra las versiones implicadas. Usa esta guía para definir y comprobar tu compromiso de compatibilidad; no supongas que un script de migración universal puede hacer compatible cualquier actualización del motor.
Define el contrato de compatibilidad
Decide qué versiones publicadas admitirá la próxima compilación antes de cambiar el estado que guarda. Establece políticas explícitas para las partidas guardadas normales, los desbloqueos persistentes, los ajustes y las partidas guardadas exportadas desde el navegador; pueden necesitar tratamientos diferentes. Avisa a los jugadores con antelación cuando pueda ser necesario empezar de nuevo.
Mantén un identificador de lanzamiento y, cuando controles el formato de guardado, una versión del esquema. Separa el progreso en el contenido de los ajustes de presentación y los datos derivados. Antes de cambiar un campo persistente, registra su significado y su valor predeterminado.
Prioriza los identificadores estables
Asigna a las rutas y escenas identificadores estables que se mantengan tras las reescrituras y la traducción. Conserva esos identificadores intactos mientras prometas compatibilidad. Si uno debe cambiar, planifica una migración o señala claramente el límite a partir del cual las partidas guardadas antiguas dejan de tener soporte.
Si gestionas un formato de guardado propio, almacena datos simples, documenta el esquema y valida los datos entrantes antes de usarlos. Las partidas guardadas nativas del motor pueden depender de otras reglas de serialización. Sigue las indicaciones del motor antes de sustituir un sistema de guardado fiable por un serializador casero.
Planifica una migración antes de cambiar el estado
Escribe el plan de migración antes de cambiar un campo: el campo antiguo, el nuevo, la regla de conversión y la alternativa para datos ausentes o inesperados. Haz que las migraciones sean deterministas y repetibles cuando el formato lo permita. La ausencia de un campo no relacionado nunca debe conceder progreso.
Para Ren'Py, sigue sus indicaciones sobre guardado y retroceso y las notas de compatibilidad aplicables a tus versiones. Para SugarCube, comprueba la versión exacta del formato y las API de guardado. Para un estado personalizado en Godot, implementa y prueba el esquema que gestionas. Una regla que funciona en un sistema puede no servir en otro.
Mantén una biblioteca de partidas guardadas representativas
Crea una biblioteca de partidas guardadas que cubra el inicio, los momentos justo antes de decisiones importantes, cada ruta principal y la aproximación al final. Incluye distintos desbloqueos, ajustes y versiones antiguas que todavía admitas. Usa estados de desarrollo anonimizados y evita recopilar datos de jugadores que no necesites.
Haz las pruebas con copias y deja los originales intactos. Registra de qué lanzamiento procede cada partida guardada y el estado que esperas tras cargarla. Cargar sin que se produzca una excepción es solo la primera comprobación: una partida guardada aún puede colocar al jugador en la ruta equivocada, duplicar una recompensa o perder un ajuste.
Prueba una actualización real
Prueba la compilación empaquetada mediante el proceso de actualización que los jugadores usarán realmente: instálala o sírvela desde un servidor, según corresponda. Carga una partida guardada antigua, continúa a través de una escena significativa, guarda de nuevo y vuelve a cargar. Comprueba el progreso persistente y los ajustes por separado.
En las compilaciones para navegador, comprueba el origen, el comportamiento del almacenamiento y el contexto de alojamiento cuando el juego está incrustado. Un cambio de URL o de contexto de almacenamiento puede afectar al acceso a los datos existentes aunque la lógica del juego no cambie. Si ofreces exportación e importación, verifica esa vía de recuperación y explica sus límites.
Publica información clara sobre la recuperación
Publica el proceso de actualización admitido, el método de copia de seguridad y los límites de compatibilidad conocidos donde los jugadores puedan encontrarlos. Haz que el formulario para informar de errores solicite detalles útiles sobre las versiones. Si un lanzamiento no puede conservar de forma segura una categoría de partidas guardadas, explica ese límite antes de que un jugador sobrescriba su última copia válida.
Archiva la compilación probada, las notas del esquema y la matriz de partidas guardadas junto con cada lanzamiento. Mantén las decisiones de migración vinculadas a las revisiones del código fuente. Las comprobaciones periódicas de compatibilidad facilitan el mantenimiento y te permiten detectar fallos antes que los jugadores.
Decisiones clave
- Indica los lanzamientos admitidos y establece una política para cada categoría de partidas guardadas.
- Mantén ID estables y documenta el significado y el valor predeterminado de cada campo.
- Tras la migración, comprueba el progreso, luego guarda y vuelve a cargar.
- Protege las partidas guardadas originales y explica a los jugadores cómo recuperarlas.
Archivos de la guía
Matriz de pruebas ↓Las comunidades externas dedicadas a modelos y los sitios externos de publicación pueden contener material explícito. Los enlaces a las fuentes se abren en una pestaña nueva; esta guía no carga sus vistas previas.
Fuentes y lecturas adicionales +
- Referencia de guardado y retroceso de Ren'Py ↗
- Cambios incompatibles de Ren'Py ↗
- Guardar partidas en Godot ↗
- Referencia de SugarCube ↗
Última comprobación 5 de octubre de 2026.