Una elección importa cuando la historia la recuerda. Este proyecto para principiantes sigue a dos colaboradores adultos que deciden cómo abrir un estudio, con un pequeño grafo de pasajes, una decisión almacenada y dos finales. Necesita muy pocos recursos gráficos. Tu primera tarea es hacer que cada elección lleve al resultado previsto y, después, que ese resultado se conserve tras guardar y volver a cargar.
La descarga contiene el código fuente Twee para SugarCube. Compílalo en HTML jugable con Tweego y un formato de historia SugarCube instalado, o recrea manualmente los pasajes de la historia en Twine. Aquí no se ha ejecutado el ejemplo en un entorno de ejecución de Twine, así que completa las pruebas que se indican a continuación antes de publicarlo.
Elige primero el formato
Crea una historia en Twine, selecciona SugarCube 2 como formato de historia y anota la versión que uses. Ten a mano su documentación oficial sobre macros, variables y guardados. Los ejemplos de Harlowe usan una sintaxis diferente; copiarlos directamente en SugarCube es una forma rápida de convertir una escena sencilla en una sesión de depuración.
En el código fuente descargado, las líneas que empiezan con :: introducen los pasajes. StoryTitle y StoryData contienen información de configuración. En el editor de Twine, establece el título de la historia y el formato SugarCube y, después, crea StoryInit y los seis pasajes de la historia con sus nombres exactos. Copia el contenido de cada uno sin su encabezado :: y selecciona Start como pasaje inicial. Un archivo .twee es código fuente editable; publica HTML para los jugadores.
Construye el grafo de pasajes
El ejemplo inicializa $sharedPlan en false. Start ofrece dos respuestas: SharedPlan la establece en true, mientras que SeparatePlan la establece en false. Ambas llevan a Discussion, que comprueba el valor y muestra el enlace a SharedEnding o IndependentEnding. Ese es todo el grafo: una decisión con una consecuencia visible.
Asigna a los pasajes nombres estables y fáciles de distinguir y revisa cada destino tanto en el grafo visual como en la compilación publicada. Una etiqueta de enlace atractiva no puede arreglar un error en el nombre del destino. Mantén el nombre interno del pasaje separado del texto que puedas reescribir o traducir, para que un cambio de redacción no rompa la ruta.
Haz que los cambios de estado sean predecibles
Usa una variable con nombre para una decisión concreta. Aquí, $sharedPlan registra si el jugador eligió un plan compartido; no tiene que representar todos los sentimientos entre los personajes. Asígnale un valor donde se toma la decisión y léelo donde aparece la consecuencia. Mantener clara esa relación facilita ampliar una historia pequeña.
Comprueba qué ocurre cuando un jugador vuelve a visitar un pasaje. Si mostrarlo añade un punto, una visita posterior puede otorgar otro sin querer. En proyectos más grandes, establece reglas propias para los eventos que solo deben ocurrir una vez y decide si retroceder por el historial de la historia debe deshacer sus efectos. Prueba también las recargas, en lugar de asumir que se comportan como una primera visita.
Diseña una página legible
Empieza con la interfaz predeterminada del formato de historia. Dale al texto un ancho cómodo para leer, usa una tipografía legible y haz que el foco del teclado en los enlaces sea claramente visible. Revisa los párrafos y las opciones en una pantalla estrecha. Una capa decorativa sirve de poco cuando el jugador no puede encontrar la siguiente línea; añade fondos elaborados solo cuando la lectura resulte fluida.
Haz que sea fácil encontrar los ajustes y los controles para reiniciar y guardar. No uses solo el color para identificar los enlaces disponibles o un estado importante, de modo que la página siga siendo comprensible si se pasa por alto una señal de color. Si añades audio o movimiento, ofrece controles y empieza de forma discreta. Deja que los jugadores elijan cuándo se incorpora a la escena la banda sonora o la animación.
Publica y prueba la persistencia de los datos
Publica mediante Twine o compila el código fuente en HTML con el formato SugarCube seleccionado y, después, sirve ese archivo desde el alojamiento previsto. Pruébalo en el navegador y en el origen del sitio que usarán los jugadores. El almacenamiento del navegador está ligado a su contexto, por lo que un guardado local correcto no basta para determinar cómo se comportará la versión alojada.
Guarda antes de la decisión y otra vez después. Cierra la página, vuelve a abrirla y carga cada guardado, comprobando que la elección recordada y el final disponible sean correctos. Repite la prueba en un perfil nuevo del navegador y crea allí nuevos guardados. Comprueba por separado la navegación privada, el almacenamiento borrado y la distribución integrada en otra página. Describe los límites que encuentres; los ajustes del navegador y el comportamiento del alojamiento pueden impedir que los guardados persistan.
Prepara un proceso de actualización
Mantén el código fuente editable bajo control de versiones y archiva cada versión HTML publicada. Registra la versión de SugarCube y los cambios en los pasajes y conserva archivos de guardado representativos para poder comparar una actualización con la compilación anterior. Decide si las actualizaciones admitirán los guardados existentes. Si los jugadores deben empezar de nuevo, explica ese requisito antes de que carguen la nueva versión.
Juega cada final desde el principio y comprueba todos los enlaces con el teclado y, cuando corresponda, con controles táctiles. Usa la matriz de pruebas de rutas para registrar los resultados esperados y los reales. Puedes seguir adelante cuando la historia se lea con claridad, su estado se comporte de forma predecible y puedas repetir el proceso de publicación. Consulta la guía de rutas y estados antes de construir una gran red de ramificaciones.
Decisiones clave
- Selecciona SugarCube 2 antes de escribir macros de SugarCube.
- Conserva el código fuente Twee; publica HTML jugable.
- Prueba las visitas repetidas, los guardados y las recargas en el alojamiento previsto.
- Mantén estables los nombres de los pasajes y archiva las versiones publicadas.
Archivos de la guía
Ejemplo Twee para SugarCube ↓Matriz de pruebas de rutas ↓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 +
Última comprobación 5 de octubre de 2026.