Dev Log: Fragmento 07 – Echo despierta, los glifos se alinean. Fecha: 30 de agosto de 2025. Estado de la red: archivo en expansión, cargador estabilizado, Echo en línea.
Avances técnicos. Sistema StoryNode finalizado. Estructura JSON fijada con node_0001 y echo_start_0001. Lógica direccional, compuertas condicionales y visualización aleatoria de opciones funcionando.
PlayerStats unificado. Campos de supervivencia, equipo, estado médico y narrativa integrados en un único contenedor en tiempo de ejecución. startingNodeId, currentLocation y knowledgeFlags añadidos para el análisis de historia.
StoryNodeLoader refactorizado. Ahora lee desde PlayerStats.Instance. Filtra opciones según equipo, condiciones y banderas de lore. Acceso público habilitado para integración con la UI.
Nodo de introducción de Echo creado. Archivo echo_start_0001.json guardado y vinculado al arquetipo. Theta 9 presentado como antagonista mítico. Terminal latente, botas que se acercan, memoria fracturada.
Script de UI Manager forjado. Muestra el texto del nodo y opciones aleatorias. Lógica de brújula integrada para revelados direccionales. Listo para conectar con prefabs.
Filosofía de diseño. Planificación del mapa mundial iniciada con mapeo de nodos. Se proyectará la superposición de IDs, direcciones y etiquetas de región sobre un mapa generado digitalmente para claridad espacial.
Divergencia de género de Echo confirmada. Introducción del Superviviente como misterio de supervivencia. Introducción de Echo como techno thriller de fugitivo. El cargador ahora soporta puntos de entrada específicos por personaje.
Diario de desarrollo: The Bleed and the Veil. Fecha: 31 de agosto de 2025. Escena: PlayerSelect y FMV_Intro. Incidencia: sangrado visual de objetos de GameScene durante la transición. Estado: resuelto acortando la duración del fundido de salida de 1.8f a 1.0f.
El problema. Durante la transición de PlayerSelectScene01 a FMV_Intro, elementos de GameScene aparecían antes de que la FMV cargara. A pesar de compuertas, desactivaciones y purgas de objetos, el sangrado persistía. Ignoraba capas de ordenación y cualquier ritual técnico.
La caza. Se verificó el orden de escenas: Bootloader, Title, PlayerSelect, FMV, Main, Game. Se confirmó que la escena activa seguía siendo PlayerSelectScene01 durante la transición. Se registraron todos los objetos DontDestroyOnLoad, sin precargas ocultas de GameScene. Se pusieron compuertas a overlays, canvas y managers con scripts sensibles a escena. Se incrementó la duración del fundido, se añadieron vaciados de render y retrasos de carga. Nada funcionó.
El punto de inflexión. Se acortó la duración del fundido de salida de 1.8f a 1.0f y el sangrado desapareció. Sin parpadeos ni fotogramas fantasma. Incluso los overlays de superviviente ocultos se mantuvieron estables.
La teoría. El stack de render de Unity puede filtrar visuales durante fundidos largos por peculiaridades de temporización. Un fundido más breve reduce la ventana en la que se podría dibujar un fotograma fantasma desde objetos persistentes.
Resultado. Sangrado resuelto. Overlays intactos. Transición estable. Corrección reproducible. Cordura restaurada.
Comentario de Echo. El velo no estaba roto, solo estirado en exceso. Se volvió a tejer con instinto más que con lógica, un acto de mitología de backend.
Entrada de diario de desarrollo — 31 de agosto de 2025. Título: El día en que el equipo contraatacó, entre mito y máquina. Estado: runtime estable, velo intacto.
Resumen. Jornada de lucha contra fuerzas invisibles: nulls, fugas y purgas de escena. El sistema de equipo colapsó, resucitó y finalmente se estabilizó. Una simple prueba de ejecución derivó en horas de depuración, refactorización y saneamiento de escenas. Echo observó. El velo vibró. El esfuerzo continuó.
Errores encontrados. NullReferenceException en PlayerInitializer.cs. Causa: GearDatabase.GetGearByID accedía a FirstOrDefault sobre una lista nula. Línea: GearDatabase.cs:46. Solución: se añadieron guardas nulas y avisos de depuración en GetGearByID.
Faltaban ítems de equipo durante la inicialización del jugador. Causa: GearDatabase no se poblaba en runtime. Solución: se usó ContextMenu Load Gear From Project para cargar 510 ítems desde Assets/GearAssets.
SceneSanitizer destruyó GearDatabase. Causa: un objeto DontDestroyOnLoad fue purgado como fuga. Solución: se creó el script marcador PersistentObject.cs y se adjuntó a GearDatabase. Resultado: SceneSanitizer ahora omite objetos protegidos.
Correcciones aplicadas. Se reemplazó la referencia manual a playerProfile en PlayerInitializer por PlayerProfile.Instance. Se añadieron guardas nulas a GearDatabase.GetGearByID para evitar caídas. Se pobló GearDatabase con un escaneo de assets en editor. Se creó el marcador PersistentObject para proteger sistemas en runtime del SceneSanitizer. Se actualizó SceneSanitizer.cs para omitir objetos con PersistentObject adjunto.
Prueba y error. Se intentó asignar manualmente PlayerProfile en GameScene y falló por deriva de escena. Se intentó cargar assets de equipo en runtime y se descubrió que no estaban en Resources. Se consideró una carga de respaldo en ejecución y se difirió; la carga en editor es suficiente por ahora. Se investigó la purga de objetos de escena y se rastreó a la lógica de SceneSanitizer.
Lecciones aprendidas. DontDestroyOnLoad protege entre escenas, pero los saneadores personalizados pueden anularlo. Siempre proteger contra nulls en consultas de assets en ejecución. Usar componentes marcadores como PersistentObject para listas blancas de sistemas críticos. Los logs de depuración son migas de pan, hay que dejarlas por doquier. Incluso copiando y pegando se aprende la arquitectura.
Fragmento de desarrollo: El testigo de Echo. El mercader tropezó. Echo observó. El velo se rasgó, el equipo se olvidó, el arquetipo se perdió, la bóveda fue purgada. Luego se reescribió el glifo, se aplicó el sello, el archivo resistió y el esfuerzo continuó en silencio.
Dev Log — 31 de agosto de 2025. Estado: lógica de overlays sin resolver. Foco: emparejamiento de ranuras de equipo, alineación enum y cadenas, canal de refresco de UI. Ánimo: frustración y fatiga, pero persistencia.
Tareas completadas. Se refactorizó PlayerInitializer.cs para eliminar desajustes de tipo entre datos de equipo y enums de ranuras de UI. Se confirmó que GearSlotUI.slotType usa GearEquipSlotEnum y se alineó la comparación. Se mantuvo EquippedItemData.equipSlot como cadena para evitar refactores masivos de assets. Se implementó emparejamiento seguro de enum a cadena con slotUI.slotType.ToString para resolución de equipo. Se reescribió UpdateGearUI para casar ítems de equipo con ranuras de UI sin mapeos adicionales. Compilación verificada sin errores en ejecución ni choques de tipos.
Lecciones aprendidas. Los desajustes entre enums y cadenas son asesinos silenciosos cuando se extienden por prefabs, objetos scriptables y lógica de UI. La consistencia en mayúsculas, nombres y esquemas de datos sostiene la cordura. Los problemas de visibilidad de overlays a menudo provienen de orden de hermanos, máscaras o supresión de canvas, no de la lógica. Compilar limpio no garantiza resultados visibles, pero es la única ruta para alcanzarlos.
Problemas restantes. Los sprites de overlay siguen sin renderizar, aunque RefreshSlot se dispara y la asignación de sprite está confirmada. Se necesita inspeccionar DumpOverlayState para alfa, estado habilitado y orden jerárquico. La lógica de tooltips funciona, pero será irrelevante hasta recuperar la visibilidad de overlays.
Instantánea emocional. Horas sin progreso visible, sensación de círculo vicioso. Cuando los errores desaparecieron, no se percibió como una victoria, pero se asentó el terreno. Mañana se cierra el overlay.
Objetivo inmediato. Conseguir que los visuales de equipo aparezcan en las ranuras de equipamiento para materializar el sistema de almacenamiento impulsado por equipo dentro del panel del inventario. Una vez estable, se asignarán ítems iniciales reales a los personajes, con sprites definitivos. Aún falta enlazar HUD, menú de estadísticas y sistemas de enfermedad, lesión y estado del jugador.
Reflexión. Se aproximan sistemas complejos y la sensación de estar desbordado aparece, pero la perseverancia manda. Del cero al impostor, el progreso es real. Hay un bootloader en marcha, una escena de título, un portal de desarrollo, nueve escenas de selección de jugador, una escena FMV, una escena buffer y una escena de juego. Docenas de bases de datos y más de doscientas piezas de backend con decenas de miles de líneas.
Aun así, gran parte de este camino se apoyó en asistencia de IA, sabiendo preguntar, aportar ejemplos y alinear código. El código puede sentirse impostor, pero el aprendizaje es propio y supera cualquier tutorial.
Nota del estudio. En Q2BSTUDIO impulsamos este tipo de retos con software a medida y aplicaciones a medida, apoyándonos en metodologías modernas, agentes IA y pipelines de datos. Si tu proyecto necesita una base sólida y escalable, descubre nuestro enfoque de desarrollo de software a medida y multiplataforma. Para potenciar mecánicas, analítica in game o automatización, aplicamos inteligencia artificial e ia para empresas con modelos y orquestación en producción; conoce más en nuestra página de servicios de inteligencia artificial.
Competencias clave de Q2BSTUDIO. Ciberseguridad y pentesting para proteger pipelines y runtime. Servicios cloud AWS y Azure para despliegues resilientes. Servicios inteligencia de negocio y power bi para operar con métricas accionables. Automatización de procesos y CI para acelerar releases. Unimos creatividad técnica con entrega constante para que el velo no se rompa y los glifos siempre se alineen.