Convertir «El ciclo de vida del cuerpo de software» en una Visual Novel jugable: una retrospectiva completa de una iteración
Esta vez no se trató de “ponerle una skin de lector”, sino de tomar el texto completo 软件体的生命周期.md y transformarlo de verdad en una novela visual jugable al estilo japonés (GALGAME), cumpliendo de principio a fin una restricción dura: del texto original solo se puede añadir, no se puede quitar; no se puede perder ningún detalle textual.
Todo el proceso no salió de una sola vez, sino que fue la típica iteración continua de “primero hacerlo funcionar y luego ir puliendo poco a poco lo que chirría”. Mirándolo en retrospectiva, básicamente se puede dividir en las siguientes fases.
1. El punto de partida estaba claro: no era una adaptación por extractos, sino una transformación fiel del texto completo
Desde el inicio, el objetivo era inflexible:
- El guion venía del archivo local
软件体的生命周期.md - Todo el texto debía entrar en el juego
- No se podía, por convertirlo en juego, recortar el original hasta dejarlo en un resumen, una versión en diálogos o una versión de novela ligera
- La presentación del texto se podía reforzar, pero el contenido textual en sí no podía encogerse
Por eso, la idea de fondo de este proyecto no era “escribir un guion de VN”, sino “cortar el texto original en una estructura de párrafos adecuada para el avance de una novela visual, conservando a la vez el original completo para poder revisarlo”.
Más adelante, en todo el sistema, cosas como la navegación por capítulos, la vista general del original, la localización por párrafos, la relectura y el guardado de progreso, en realidad giran en torno a este supuesto.
2. La primera versión corría, pero no parecía una Visual Novel
Tras la primera versión, el mayor problema no era la falta de funciones, sino que no tenía el “aire” adecuado.
Aunque ya se podía avanzar el texto, mostrar el contenido y segmentarlo, la interfaz se veía más como un lector web con un panel de control que como un GALGAME japonés. La primera reacción del usuario también fue muy directa: “Esta interfaz no está bien en absoluto; hazla con una UI como la de los galgame japoneses.”
Así que en la primera ronda de refactorización, el foco no fue añadir funciones, sino corregir primero el lenguaje visual:
- Separar de nuevo la capa de escenario, la capa de primer plano y la capa de caja de texto
- Rediseñar el título del capítulo, la portada y las tarjetas de transición con una presentación propia de novela visual
- Cambiar la caja de texto a un cuadro de diálogo de VN fijo sobre el escenario, en lugar de una tarjeta web normal
- Hacer que el área de parlamento del personaje, la placa de nombre, la barra de progreso y el botón de avance se parezcan más al layout típico de una novela visual japonesa
El sentido de esta ronda fue: primero lograr que se vea como un juego, y luego seguir completando la interacción que un juego debe tener.
3. Completar las ilustraciones de personajes: el escenario pasó de “tener imágenes” a “parecer un escenario”
El usuario planteó un requisito claro: cada personaje debía tener su ilustración (sprite).
Así que lo que se hizo después no fue asignar imágenes a unos pocos protagonistas al azar, sino montar de verdad el sistema de sprites de personaje:
- Gestión independiente de los datos de sprites
- Cada personaje con su propia posición en el escenario y estilo de visualización
- Disposición para un personaje, varios personajes y varios en escena a la vez
- Al hablar, el personaje activo se realza; los que escuchan se atenúan
- El texto de diálogo de distintos personajes admite colores correspondientes
Pero esta parte también pasó por muchas rondas de pulido. Entre medias aparecieron varios problemas típicos:
- Algunos personajes solo se mostraban de cintura para abajo
- La caja de texto era demasiado grande y tapaba el escenario
- Cuando había varios personajes en escena, el escenario se veía muy apretado
- En las miniaturas de guardado, los sprites a menudo quedaban decapitados o solo quedaban las piernas
Luego, en torno a estos problemas, se hicieron muchas correcciones:
- Ajustar la altura del escenario y la lógica de escalado de los sprites
- Diferenciar tres tamaños de sprite: human / digital / entity
- Permitir el desplazamiento horizontal, vertical y el zoom del escenario
- Diseñar una distribución de slots más razonable para varios personajes en escena
- Arreglar la composición de las miniaturas para conservar lo más posible la figura completa y evitar que el personaje quede destrozado por el recorte en la tarjeta de guardado
Al final, dejó de ser simplemente “poner unas imágenes”, y empezó a tener una clara sensación de puesta en escena.
4. La libertad de la caja de texto casi se convirtió en un sistema de layout ajustable
En este proyecto, la caja de texto fue una de las partes que más vigiló el usuario y también la que más se profundizó después.
El usuario planteó de forma consecutiva muchos requisitos muy concretos:
- Permitir al usuario personalizar la posición de la caja de texto
- Permitir ajustar el tamaño desde las esquinas
- Permitir ajustar la transparencia
- Permitir que la velocidad del texto, al máximo, aparezca instantáneamente
- Permitir distintos colores de texto según el personaje
- La caja de texto no puede estar bloqueada a ancho completo
- Puede hacerse más estrecha o más ancha
- No puede tapar siempre los sprites
- En orientación horizontal (layout a la derecha) debe colocarse en el extremo derecho
Así que después no se hizo simplemente “arrastrar la caja de texto”, sino que poco a poco se convirtió en un sistema de layout completo:
- Soporta arrastrar para mover la caja de texto
- Soporta escalado en ocho direcciones desde los cuatro lados y las cuatro esquinas
- Soporta ajuste libre de ancho y alto
- Soporta layouts predefinidos: centrado, abajo izquierda, abajo derecha, arriba izquierda, arriba derecha
- Soporta ajuste de transparencia, tamaño de letra e interlineado
- Soporta guardar el progreso tras personalizar y restaurarlo la próxima vez
- Los cambios de posición de la caja de texto se coordinan con el “apartado” del escenario para reducir la oclusión de personajes
Aquí hubo un giro clave:
Al principio, aunque se admitía cambiar el tamaño, seguía existiendo el problema de “lo más estrecho sigue siendo a ancho completo” y de “visualmente parece bloqueado”. Después se corrigieron específicamente el ancho mínimo, el ancho por defecto y la lógica de tamaño personalizado, y solo entonces se logró de verdad esa transformación libre que quería el usuario, y no un “parece ajustable, pero en realidad no se puede”.
5. Título, transiciones de capítulo e información de marcador de posición: restar una y otra vez
Otro rumbo claro de iteración fue ir quitando poco a poco la UI sobrante que interrumpía la lectura.
El usuario mencionó varias quejas muy típicas:
- ¿Pueden desaparecer automáticamente esos dos recuadros de la esquina superior izquierda, sin dejar marcadores?
- Que el título del libro y el gran encabezado de “capítulo x” solo aparezcan una vez al cambiar de capítulo, no que salten en cada frase
- No colgar siempre algunos bloques explicativos en pantalla
Así que después se hicieron varias rondas de “aparecer solo cuando debe aparecer”:
- La portada / título de capítulo pasaron a mostrarse brevemente solo cuando hay un cambio real de capítulo
- En estado de lectura normal se ocultan automáticamente los grandes títulos y recuadros de marcador
- En escenas sin sprite ya no se muestra una gran tarjeta vacía de marcador
- El HUD superior se desvanece automáticamente tras inactividad
- Los avisos de lectura en escritorio se retiran automáticamente tras inactividad
- Los avisos de arrastre y las asas de escalado se atenúan durante la lectura tranquila y solo vuelven al interactuar
- Las etiquetas junto a los pies del sprite se desvanecen automáticamente en lectura tranquila y se iluminan de nuevo al interactuar o cambiar de personaje
En realidad, toda esta serie de ajustes hace lo mismo:
Bajar la “sensación de interfaz de herramienta” y subir la “sensación de puesta en escena de lectura”.
6. Completar el modo de avance: la experiencia operativa se parece más a una novela visual real
Además del avance básico, después se completaron bastante bien los hábitos de interacción habituales de VN:
- Clic fuera de la caja de texto para avanzar
- Rueda del ratón: siguiente / anterior
- Espacio, Enter, teclas de dirección para avanzar
- Reproducción automática
- Saltar lo ya leído
- Clic derecho o atajo para ocultar la interfaz
- Pulsación larga en un área en blanco para alternar ocultar interfaz (móvil)
Aquí tampoco salió bien a la primera.
Por ejemplo, un problema que se arregló recientemente fue que con los controles desplegados la rueda funcionaba, pero al plegarlos la rueda dejaba de funcionar. La causa era que el área del texto se trataba erróneamente como un área que “debía interceptar el scroll”. Luego se corrigió esa condición y se añadió una vuelta automática, garantizando que en adelante “al plegar los controles, si pones el ratón sobre el texto principal, la rueda siga avanzando / retrocediendo”.
Este tipo de correcciones, aunque pequeñas, son clave, porque determinan directamente si el producto final se parece o no a una VN de verdad que se pueda leer a largo plazo.
7. Guardado, relectura y vista general del original: aquí no son funciones accesorias, sino funciones núcleo
Como este proyecto desde el inicio exigía “fidelidad al original”, algunas funciones que en juegos normales son extras, aquí en realidad son funciones principales:
- Autoguardado
- Guardado rápido / carga rápida
- Guardado manual en múltiples ranuras
- Al cargar, restaurar posición y tamaño de la caja de texto y preferencias de lectura
- Relectura de párrafos recientes
- Navegación por capítulos
- Vista general y tabla de contenidos del original
- Desde el párrafo del juego, retrobuscar el número de línea del original y localizarlo
En particular, lo de “vista general del original” y “párrafos correspondientes a líneas del original” en realidad hace que “adaptarlo a juego” sea muy transparente:
No solo puedes avanzar dentro de la capa de juego; también puedes volver en cualquier momento a la estructura completa del original para ver exactamente en qué línea estás leyendo.
8. Miniaturas de guardado y detalles del estado de lectura: todo sale de microajustes ronda tras ronda
Más adelante, lo que realmente consumía tiempo ya no eran las grandes funciones, sino una gran cantidad de detalles del tipo “al usuario le molesta de inmediato, pero quizá no pueda explicarlo en una frase”.
Por ejemplo:
- En las miniaturas de guardado, los sprites quedan decapitados por el recorte
- Las etiquetas junto a los pies del sprite parecen demasiado información de depuración
- Las pistas de la caja de texto y las asas de arrastre son demasiado llamativas
- El HUD superior permanente roba protagonismo
- Con varios personajes en escena, la mirada de lectura se dispersa por la UI
Estos problemas al final casi nunca se resolvieron “añadiendo más funciones”, sino controlando el ritmo:
- Qué debe mostrarse siempre
- Qué debe desvanecerse
- Qué debe aparecer solo al hover
- Qué debe mostrarse solo brevemente al cambiar de estado
Tras hacer todo esto, la sensación del juego se desplaza claramente de “una web con muchas funciones” hacia “una novela visual en la que se puede leer en silencio”.
9. La verificación automatizada es la clave para poder iterar de forma sostenida en la fase final
Después el usuario lo dijo muy claro: “Entonces, tú sigue mejorando, optimizando y verificando continuamente la funcionalidad de nuestro servicio.”
Así que a partir de ahí, no solo cambié la interfaz; también completé la cadena de verificación automática. En el proyecto hay posteriormente un conjunto de scripts de verificación de UI al estilo Playwright para comprobar repetidamente estos puntos clave:
- Si el título aparece / se oculta a tiempo
- Si la caja de texto por defecto tapa el escenario
- Si el arrastre / escalado / ajuste por imán de la caja de texto funciona bien
- Si la posición y el tamaño personalizados se pueden guardar y restaurar
- Si el HUD superior se desvanece automáticamente
- Si los avisos de lectura y las asas de arrastre se atenúan en inactividad
- Si el cajón de guardado, el autoguardado y las miniaturas del guardado rápido son correctas
- Si varios personajes en escena se salen de los límites en escritorio / móvil
- Si en móvil la pulsación larga para ocultar interfaz funciona
- Si tras plegar los controles la rueda sigue avanzando correctamente
Esto significa que las optimizaciones posteriores no son “cambio una cosa y apuesto a que otras no se rompan”, sino que se puede modificar y hacer regresión a la vez.
Esta capacidad es muy importante para un proyecto de UI tan altamente interactivo; si no, en la fase final es fácil que ocurra “arreglé A y explotó B”.
10. El estado actual del proyecto
Hasta ahora, este proyecto GALGAME de «El ciclo de vida del cuerpo de software» ya tiene una jugabilidad y legibilidad bastante completas:
- Se conserva el texto original completo, no una adaptación tipo resumen
- Interfaz principal estilo GALGAME japonés
- Integración de sprites para todos los personajes
- Diferentes personajes con diferentes colores de texto
- Transiciones de cambio de capítulo y portada del libro
- Caja de texto con arrastre libre, escalado y ajuste de transparencia
- Velocidad de texto con soporte de visualización instantánea
- Clic fuera de la caja de texto para avanzar
- Rueda: anterior / siguiente
- Reproducción automática, salto de leído, ocultar UI
- Guardado automático / rápido / manual
- Relectura, navegación por capítulos, vista general del original
- Adaptación a escritorio / móvil
- Varias rondas de pulido para “desherramientizar” la interacción
- Scripts de verificación automatizada para regresión continua
Si el objetivo inicial era “convertir un texto md en un juego”, ahora una forma más precisa de decirlo sería:
Convertir un texto largo completo en un sistema de novela visual que se puede leer, jugar, rastrear y pulir de forma sostenida.
11. Lo más interesante de este proyecto
Para mí, lo más interesante de este desarrollo no fue “hacer una página de GALGAME”, sino que todo el proceso demuestra de forma muy típica una cosa:
Hacer que algo quede realmente bien muchas veces no se logra en la primera versión apilando todas las funciones, sino porque el usuario señala una y otra vez “qué no encaja”, y luego se van eliminando esas disonancias ronda tras ronda.
En esta ocasión el feedback del usuario fue muy específico, y muchos no eran el típico “optimiza un poco más”, sino:
- Aquí tapa la pantalla
- Aquí, ¿por qué está bloqueado a ancho completo?
- Aquí, ¿por qué salta en cada frase?
- Esto solo muestra la mitad inferior del cuerpo
- ¿Por qué la esquina superior izquierda no desaparece del todo?
- ¿Por qué la rueda deja de funcionar al plegar los controles?
Fueron precisamente esos puntos muy concretos de “se ve raro” los que al final empujaron el proyecto de “se puede usar” a “tiene buena pinta”.
Si más adelante se sigue haciendo, creo que las direcciones que aún se podrían pulir incluyen:
- Un estilo más unificado de los sprites de personajes
- Una puesta en escena de capítulos más fina y un sistema de BGM/SE
- Un sistema más completo de CG / cambio de fondos
- Una capacidad más potente de orquestación de scripts
- Un método de publicación y empaquetado más formal
Pero para esta ronda, esto ya no es una demo, sino un prototipo de VN bastante completo y con capacidad de iteración continua.