Volver atrás sin romper la historia

Restaurar una versión antigua de una conversación puede terminar sin ningún error y dejar la historia rota. La conversación recupera sus nodos y su texto, pero la capitana Ilya, que decía esas líneas, ya no existe en el proyecto, y una de sus condiciones consulta la variable trust_ilya, que después cambió de nombre. El botón decía «restaurar», pero solo recuperó una parte de lo que había.

En una historia interactiva casi nada vive aislado. Una frase puede estar vinculada a una traducción y a una grabación. Una elección depende de una variable. Un personaje reaparece en conversaciones, escenas y documentos que evolucionan a ritmos distintos. Recuperar texto es sencillo. Recuperar el significado que adquiría al relacionarse con todo lo demás es mucho más difícil.

El control de versiones lleva décadas intentando hacer que los cambios sean reversibles. Su historia explica por qué, al llegar al diseño narrativo, el problema cambia.

De los archivos a las historias conectadas

En 1972, Marc Rochkind escribió SCCS en Bell Labs para registrar las versiones del código fuente y quién hizo cada cambio, cuándo y por qué. En una retrospectiva publicada cincuenta años después de su artículo de 1975, explicó que el sistema no modelaba cómo trabajaban realmente los equipos de programación. Entre las debilidades que enumera está que SCCS controlaba cada archivo de forma aislada.

Las herramientas posteriores añadieron ramas, fusiones y colaboración distribuida. Aunque sistemas como Git versionan instantáneas del repositorio, su comparación habitual sigue organizada en archivos y líneas. El diseño narrativo heredó esa infraestructura y también su desajuste: para un diseñador, lo que cambia suele ser una conversación, una escena o una decisión conectada con muchas otras.

Twine muestra a la vez el avance y lo que falta. Desde la versión 2.6, puede exportar una historia a Twee 3, un formato de texto plano cuyas cabeceras guardan la posición y el tamaño de cada pasaje, e importarla de nuevo. Su guía de control de versiones advierte que Twine comprime el HTML de las historias, lo que puede dificultar la lectura de los diffs, y sugiere convertirlas a Twee antes de guardarlas en el repositorio. También pide cerrar Twine antes de hacer pull o fusionar ramas.

Cuando un autor que guardaba su trabajo con Git pidió un pasaje por línea en el HTML de la historia, otro le recomendó versionar Twee. Ese camino también tiene sus huecos: una incidencia abierta señala que exportar a Twee e importar de nuevo elimina las etiquetas de la historia.

La investigación sobre trabajo creativo apunta en la misma dirección. Un estudio de 2022, basado en 18 entrevistas con profesionales creativos, parte de que los sistemas de control de versiones no están adaptados a sus necesidades ni a su forma de trabajar; uno de los usos que daban al historial era darse confianza y libertad para explorar.

Poder regresar con confianza permite experimentar, repartir el trabajo y revisar decisiones sin mantener carpetas llenas de copias. En narrativa ramificada, donde una modificación puede alterar rutas, estado, localización y doblaje, el historial protege la producción y la libertad creativa.

Guardar es solo la primera capa

Los problemas de persistencia siguen apareciendo, también con guardado automático. En 2025, un usuario de Inky, el editor de Ink, documentó, con los pasos para reproducirlo, que editar archivos incluidos guardados en subcarpetas anidadas podía corromperlos y perder datos. En 2026, otro usuario comprobó que, en Twine, pulsar Play, Test o Export justo después de editar un pasaje podía dejar fuera los últimos cambios; la corrección ya está en la rama de desarrollo de Twine.

Parte de la confusión viene de llamar «seguridad» a mecanismos distintos. Guardar registra el estado actual. Deshacer revierte una acción reciente. Una copia de seguridad permite sobrevivir a una pérdida. Un historial conserva decisiones separadas en el tiempo y debería explicar qué cambia al recuperar una. Una aplicación puede ofrecer tres de esas capas y seguir dejando un hueco en la cuarta.

Los archivos de texto y Git aportan portabilidad, autoría y un formato independiente de la aplicación. Son una base valiosa. Sin embargo, Git puede decir qué líneas cambiaron; no sabe por sí solo si una condición dejó una rama inaccesible o si una traducción ya no corresponde a su original. Rochkind señala lo mismo sobre el código: que dos cambios afecten a líneas distintas no significa que el archivo fusionado sea correcto, ni siquiera que compile.

Una historia se rompe entre objetos

Volvamos a la conversación de Ilya, cuyas líneas ya han empezado a localizarse. Restaurar solo sus nodos puede dejar un lienzo aparentemente correcto con un hablante ausente, una condición que no se puede resolver y una traducción desconectada. Restaurar el proyecto entero recupera a la capitana y la variable, pero también sustituye trabajo válido creado después. La dificultad está en saber qué relaciones pertenecían a aquella versión y cuáles evolucionaron después por su cuenta.

Dialogue System for Unity concreta el problema de identidad. Su manual indica que solo una persona a la vez debería editar una base de datos de diálogo, y propone usar varias bases cuando escriben varias personas al mismo tiempo. Las bases cargadas juntas necesitan IDs únicos para cada tipo de elemento. La Unique ID Tool los renumera, y el manual recomienda renumerar antes de las pruebas finales y del lanzamiento.

Renumerar tiene consecuencias para el código que usa esos IDs. En el foro de Pixel Crushers, un usuario explicó que renumerar rompería su código Lua, que leía campos de otras conversaciones por su ID, y la respuesta fue dar a cada base su propio rango, con los Base IDs separados de 10 000 en 10 000, para no tener que renumerar. Versionar contenido exige conservar también los identificadores a los que apunta el resto del proyecto.

En LegendKeeper, importar crea contenido nuevo: reimportar una exportación del mismo proyecto produce copias con IDs y enlaces internos nuevos. Recuperar contenido por esa vía da una copia con otra identidad.

La integración con el control de versiones presenta otros riesgos. articy:draft X 4.2.2 recuperó el orden determinista en los archivos de partición: tras descartar cambios, guardar un archivo revertido podía generar diferencias sin modificar su contenido. La versión 4.3.4 corrigió «Discard and Unclaim» para que también liberara los bloqueos del control de versiones.

También hay avances claros. Desde diciembre de 2025, Arcweave ofrece un historial del proyecto en los espacios de trabajo del plan Team: una línea de tiempo del proyecto completo en la que cada versión muestra quién hizo los cambios, cuándo y qué acciones se registraron. Restaurar conserva lo anterior: Arcweave crea una versión nueva que duplica la elegida, y las versiones posteriores siguen en el historial. Su granularidad es el proyecto: la restauración devuelve el proyecto entero a esa versión. La pregunta útil sigue siendo qué conserva una restauración: texto, identidad, relaciones, autoría y futuro.

Cómo abordamos el problema en Storyarn

En Storyarn versionamos unidades que el diseñador reconoce: Fichas, Flujos y Escenas. Sus revisiones pueden nombrarse y compararse mediante cambios estructurados, sin leer JSON. Antes de restaurar una versión de una Ficha, un Flujo o una Escena, Storyarn guarda el estado actual como versión de seguridad, lo vuelve a leer y lo comprueba antes de cambiar nada. Las referencias obligatorias se validan contra destinos activos del mismo proyecto; las que faltan, están mal formadas o son ambiguas bloquean la restauración en vez de eliminarse silenciosamente.

Cada mecanismo tiene su alcance. Una versión recupera una Ficha, un Flujo o una Escena, y las versiones automáticas se activan por separado para cada tipo en los ajustes del proyecto. La Papelera recupera lo que se eliminó.

Una copia de seguridad devuelve el proyecto entero al estado de la copia: sustituye las Fichas, los Flujos, las Escenas y los recursos activos, y lo actual pasa a la papelera, desde donde puede recuperarse; el proyecto y sus miembros se conservan. Restaurar una versión de un Flujo deja como están las demás Fichas, Flujos y Escenas. Dentro del Flujo recupera los nodos, las conexiones y las traducciones de esa versión, y la versión de seguridad guarda el estado anterior, con los cambios de todo el equipo, por si hay que volver a él. Después, la salud de cada editor señala cualquier referencia rota en las Fichas, los Flujos y las Escenas.

Una restauración debe decir qué unidad narrativa va a cambiar, conservar su estado actual y explicar el efecto sobre identidades y relaciones. Con la conversación de Ilya, Storyarn ya avisa de que falta su personaje y bloquea la restauración hasta que se resuelva, y la salud del Flujo señala la variable renombrada; el siguiente paso es mostrar también qué pasará con las traducciones de sus líneas.

Si has vivido un caso en el que recuperar una versión rompió una referencia, una traducción o el trabajo de otra persona, nos interesa conocerlo. Los casos límite reales son los que convierten «volver atrás» en algo en lo que un equipo puede confiar.