Bitácora 17: de .cs a .json

Bitácora de desarrollo Condicional Narrative y mejora del sistema de nodos

Ampliamos la rama de historia añadiendo el nodo node_0004 como continuación de la decisión Seguir la línea de costa hacia la derecha del nodo node_0001. Conservamos el formato JSON existente de los nodos y alineamos estilo, espaciado y metadatos con las entradas anteriores. Desde node_0004 definimos tres nuevas elecciones: Subir la duna de arena para tener mejor vista que lleva a node_0005, Seguir la costa hacia la derecha que lleva a node_0006 y Acercarse a las rocas de la orilla que lleva a node_0007. Para consistencia, clonamos el perfil de entorno de node_0001.

Presentamos un sistema de texto narrativo condicional incorporando textVariants en el JSON de StoryNode. Cada variante incluye su propio texto y de forma opcional ubicación, objetos, condiciones y requisitos de conocimiento. El cargador elige la primera variante que cumpla con el estado actual del jugador y si ninguna coincide vuelve al campo principal de texto del nodo, manteniendo compatibilidad retroactiva. Esto permite adaptar los textos según equipo equipado como botas impermeables, estado físico como lesionado o agotado, condiciones de salud como sangrado o fiebre, umbrales de stamina, banderas de enfermedades preparadas para un futuro sistema más amplio y banderas de historia generadas por elecciones previas.

Cambios de código clave. En StoryNodeLoader añadimos el método público GetNodeTextForPlayer para resolver el texto correcto y VariantMatchesPlayer para comprobar requisitos de variantes contra las estadísticas del jugador. Mantuvimos intacta la lógica IsChoiceVisible para filtrar opciones y toda la compatibilidad hacia atrás. En StoryUIManager actualizamos DisplayNode para llamar a nodeLoader.GetNodeTextForPlayer en lugar de usar node.text directamente, conservando el comportamiento de la interfaz como ocultar botones, barajar y mostrar dirección de la brújula si el jugador tiene el objeto. No duplicamos lógica, la resolución de variantes sucede solo en el cargador. En la clase StoryNode agregamos la lista textVariants y creamos la clase TextVariant con los mismos campos de requisitos que Choice.requires.

Beneficios de flujo de trabajo y pruebas. No editamos JSON en tiempo de ejecución, todas las variantes viven en datos estáticos y se eligen al vuelo. Una única fuente de verdad centralizando la coincidencia de variantes en el cargador. Preparado para el futuro, añadir nuevos tipos de condición implica actualizar VariantMatchesPlayer. Amigable para depuración, podremos registrar qué variante se eligió y por qué. Excelente para playtests, funciona en paralelo con scripts simulados de equipo para ver cambios narrativos al activar o desactivar estados. Sumamos un modo ligero de depuración que cuando está habilitado muestra la variante seleccionada, las que se descartaron y los requisitos exactos de cada una; al deshabilitarlo, el cargador opera en silencio.

Bitácora 5 sept 2025 Proyecto: renovación de sistemas de armas. Tema central: adiós base de datos monolítica, hola JSON. Migramos desde un ScriptableObject RangedWeaponItemDatabase gigante a un flujo limpio basado en archivos. Exportamos todos los datos de armas a JSON legible y construimos un RangedWeaponImporter que lee el JSON y genera activos RangedWeaponItem individuales. Ajustamos el validador de equipo para rango. Ahora cada arma es su propio archivo .asset, fácil de editar, amigable con control de versiones y sin errores globales por un simple typo.

Hicimos cruzada por la seguridad de tipos. Antes compatibleAmmoTypes era una lista de cadenas, hoy es una lista de un enum, con el importador convirtiendo cadenas de JSON a enums y avisando valores desconocidos. Las piezas también guardan su tipo de munición como enum y la compatibilidad se comprueba con comparaciones directas sin conversiones a texto.

Puesta a punto del sistema de accesorios. Arreglamos IsAttachmentCompatible para enums. Simplificamos GetCombinedModifiers con un helper WeaponStatModifier.FromFloats para iniciar valores por defecto de forma segura, sin tener que inicializar campo a campo.

Rehabilitamos depuradores. Retiramos scripts dependientes de la antigua base a una carpeta archivada y los convertimos al patrón de listas asignadas por Inspector. AmmoTypeDebugger ahora usa listas tipadas; AttachmentCompatibilityDebugger comprueba compatibilidades por arma; WeaponDebugger localiza por nombre y calcula estadísticas finales con modificadores; WeaponStatSheetDebugger imprime hoja completa; WeaponNullCheckDebugger detecta nombres faltantes, accesorios nulos y modificadores vacíos. Todo con comprobaciones de nulos y compilación limpia.

Evolución de modos de disparo. Añadimos fireMode y semiAutoRate al item de arma a distancia. FireModeController arranca en semi o auto según el arma, permite alternar en armas selectivas, aplica modificadores de accesorios, limita tasas a mínimos seguros y queda listo para integrarse con sistemas de proyectiles, munición y efectos.

Resucitamos WeaponStatModifier como struct serializable con los campos adecuados y un helper FromFloats. Se usa de forma consistente en importador, accesorios y depuradores. Resultado final del día: pasamos de más de doscientos errores a cero. Código más limpio y modular, pipeline de datos preparado para crecer, herramientas de depuración reutilizables y seguridad de enums que evita corrupción silenciosa por errores tipográficos.

Lecciones aprendidas. Las cadenas son poesía, no tipos de munición. Si no puedes borrar un sistema legado sin romperlo todo, sustitúyelo pieza a pieza hasta que pida ser retirado. Inicializa siempre tus structs, los multiplicadores no inicializados arruinan el balance. Un buen importador es como un portero, deja entrar datos correctos y expulsa los inválidos con aviso.

Bitácora 6 sept 2025 Manifiesto cuerpo a cuerpo. Migramos toda la base de armas melee a JSON modular, preservando fidelidad de estadísticas para cuchillos, mazas y lanzas. Partimos los datos en siete bloques listos para pegar por limitaciones de raíz única en JSON. Añadimos 35 armas melee únicas. Creamos un extractor por bloques que lee MeleeWeapons.json y escribe un archivo por arma, evitando duplicados, limpiando nombres de archivo y sin sobreescribir datos de rango. Cada arma vive en StreamingAssets Data WeaponExtracted.

Unificamos validación con WeaponJSONValidator que detecta si el objeto usa weaponName o itemName y aplica verificaciones de campos requeridos, rangos válidos y accesorios nulos. Es un validador incansable que revisa tu precisión con lupa. Reconstruimos el importador de melee, ahora analiza enums correctamente, maneja campos anulables y genera .asset en Assets ItemAssets MeleeWeapons. Se registró en el menú Tools, resolvimos errores de Enum.TryParse añadiendo using System y el menú aparece mediante el atributo MenuItem.

Problemas y arreglos del día. Error de parseo por texto adicional tras cerrar el contenido JSON causado por múltiples bloques raíz, solucionado unificando en un único arreglo. Error de compilación por no reconocer Enum arreglado importando el espacio de nombres adecuado. Importador que no aparecía en menú corregido encapsulándolo como EditorWindow y registrándolo con el atributo de menú. Incompatibilidades de enums resueltas verificando estructura y esquema JSON. Conclusión práctica: JSON exige una sola raíz y cero sorpresas, y cada arma merece su propio asset, incluso un humilde cuchillo de mantequilla. Total de armas únicas hasta ahora 85. Próximos pasos: herramientas de uso mixto, objetos varios, líquidos y contenedores, alimentos enlatados, carnes, frutas, verduras y semillas, utensilios de cocina, items mecánicos, ambientales y todo lo que aún falte. El avance es lento, pero es avance.

En Q2BSTUDIO vivimos estas transformaciones todos los días en proyectos reales, creando aplicaciones a medida y software a medida que convierten bases de datos monolíticas en pipelines flexibles y mantenibles, integrando validadores, importadores y automatizaciones para reducir errores y acelerar despliegues. Si buscas llevar tu plataforma al siguiente nivel, descubre cómo abordamos la ingeniería de producto de principio a fin en nuestro servicio de desarrollo de aplicaciones y software multiplataforma a medida.

Combinamos inteligencia artificial aplicada, agentes IA, ciberseguridad y pentesting, servicios cloud AWS y Azure, así como servicios de inteligencia de negocio y power BI, para que tu narrativa dinámica, tus sistemas de juego o tus aplicaciones corporativas evolucionen con datos fiables, tipados y seguros. También impulsamos la eficiencia con automatización de procesos, orquestando validaciones, importaciones y despliegues con un enfoque reproducible y auditable. Conoce más sobre nuestras estrategias de automatización en automatización de procesos de software.

Q2BSTUDIO es tu socio tecnológico para llevar ideas desde el .cs al .json y más allá, con gobernanza de datos, seguridad por diseño y escalabilidad en la nube, para que el progreso, por pequeño que sea, siempre cuente.