En ingeniería de software, un documento técnico (Technical Design Document - TDD) es necesario reducir ambigüedades y facilitar la implementación y mantenimiento del sistema. En el contexto del desarrollo de un juego como Feudalia, realizado bajo una metodología SCRUM, el documento debe integrar aspectos técnicos detallados pero adaptables a iteraciones ágiles.

En este apartado se pretende traducir requisitos funcionales en componentes técnicos, para especificar cómo se implementarán los requisitos, qué capacidades debe tener el sistema, evitar ambigüedades y facilitar la estimación en la planificación de los sprints.

• Rendimiento: 60 FPS con 4 jugadores activos.
• Conectividad: Cliente-servidor usando herramientas facilitadas por godot.
• Modularidad: Actualización lógica centralizada en controladores (GameManager, ResourceManager) en lugar de bucles independientes por nodo, y calidad de código, según los Estándares de diseño.

• Motor: Godot 4.5.
• Lenguaje: GDScript.
• Red: Hasta 4 jugadores.

• Cada jugador usa su propia instancia.
• No hay cambio de escena durante la partida.
• Carga dinámica de cuadrantes visibles.

• Godot 4.5.1
• GDQuest Utils Library (FSM, pathfinding)
• ENet (servidor dedicado)

Este apartado describe la estructura de alto nivel del sistema que compone Feudalia.
Define los principales componentes, escenas, scripts y su interacción, buscando garantizar modularidad, mantenibilidad y escalabilidad.

Feudalia sigue una arquitectura modular basada en escenas (Scenes-Modules), donde cada componente del juego es una escena autocontenida con scripts y jerarquías especializadas.

Patrón usado: Modelo-Vista-Controlador adaptado a Godot

• Vista: Nodos de tipo Control, Sprite2D, TileMap.
• Modelo: Scripts que contienen datos (*.gd como Resource.gd, Troop.gd).
• Controlador: ResourceManager.gd, orquestan las interacciones.

El sistema de red de Feudalia está diseñado bajo un modelo cliente-servidor autoritativo, donde el servidor central controla la lógica principal del juego y los clientes se encargan únicamente de enviar órdenes y mostrar el estado sincronizado.

Esta estructura garantiza equidad, estabilidad y protección contra trampas, a la vez que permite partidas fluidas entre hasta 4 jugadores simultáneos.

• Tipo: Cliente-Servidor Autoritativo.
• Roles:
  • El servidor gestiona todos los cálculos (batallas, recursos, economía).
  • Los clientes sólo envían comandos de usuario y renderizan el estado sincronizado.

Ejemplo de comunicación:

1. Cliente envía hace la acción de construcción de una casa.
2. Servidor valida recursos y posición → instancia edificio.
3. Servidor envía broadcast al cliente.

• El servidor es único responsable de validar cualquier acción de juego.
• Los clientes no pueden instanciar ni destruir ciertos nodos críticos.
• Los comandos de clientes son validados según contexto y recursos disponibles.

La interfaz de Feudalia busca un equilibrio entre claridad funcional y estética medieval minimalista.
Todo el diseño UI se implementa mediante nodos específicos de Godot, manteniendo una disposición modular (Estándares de diseño) y adaptable a diferentes resoluciones. Tenemos la interfaz de entrada, con el botón de play, la ciudad por la que se recolecta y construye, y el campo de batalla como escenas diferenciadas. También tenemos interfaces dentro del contexto de recolección, como el menú de construcción o el menú de investigación en soldados.

• Feedback táctil y auditivo (clic, selección, construcción).
• Notificaciones dinámicas: Se muestran durante al menos 3 s o hasta interacción.
• Tutorial guiado: Muestra mensajes progresivos.

El sistema de IA en Feudalia gobierna tanto a los aldeanos del jugador (automatización de tareas) como a los soldados NPC controlados por la máquina en el combate.

• Basada en Máquina de Estados Finita (FSM).
• Estados:
  • Idle → SearchResource → Collect → Deliver → Idle.
• Prioridades:
  1. Tareas manuales asignadas por el jugador.
  2. Recolección automática si hay recursos cercanos.
  3. Descanso si no hay tareas activas.
• Comportamiento afectado por:
  • Distancia a recurso.
  • Nivel de eficiencia de edificio de recolección asociado.

• Basada en árboles de comportamiento (BehaviorTree):
  • Nodo raíz: “Decidir acción”
  • Hojas: “Atacar”, “Defender”.
• Variables de decisión:
  • Proporción de tropas enemigas / aliadas.
  • Salud media del ejército.
  • Posición del objetivo más cercano.
  • Nivel y tipo de la tropa.
• Dificultad ajustable por coeficientes (aggressiveness, reaction_time).

• Cálculos ejecutados cada 500 ms por entidad.
• Uso de colas de tareas (TaskQueue.gd) para balancear carga entre frames.

El proceso de pruebas se integra dentro del ciclo SCRUM, ejecutándose en cada sprint para asegurar calidad y estabilidad.

• Herramienta: Desarrolladas manualmente por el equipo.
• Cobertura objetivo: >80 % de funciones críticas.

Las pruebas de integración validan la interacción entre distintos módulos funcionales del sistema, asegurando que el flujo de datos y los eventos entre componentes funcionen correctamente.

• Construcción de edificios
• Combate entre dos jugadores
• Sincronización de recursos multijugador

Estas pruebas garantizan que el juego cumpla los estándares mínimos de fluidez y consumo de recursos, especialmente en entornos de hardware medio.

• CPU: Intel i5-9400F
• GPU: GTX 1050
• RAM: 8 GB
• Resolución: 1280x720
• Jugadores activos: 4
• Entidades simultáneas: hasta 300 (unidades + aldeanos + edificios)

• FPS estable: ≥ 60 FPS sostenidos durante 10 minutos de juego.
• Memoria RAM: ≤ 400 MB utilizados en tiempo real.
• Consumo CPU: ≤ 70% en tareas intensivas (batalla, construcción masiva).
• Ciclo de recolección de recursos: promedio ≤ 1 s por loop.
• Tiempos de carga de escenas: ≤ 1.5 s en mapa completo.

Una funcionalidad se considera finalizada solo si cumple con los siguientes criterios descritos en el documento citado.

Riesgo	Prob.	Impacto	Mitigación
Desincronización multijugador	Alta	Muy alto	Sincronización controlada por servidor, validación de estado y logs de red
IA sobrecargada	Media	Alto	Intervalos de cálculo, agrupamiento de decisiones, limitación de entidades
Retrasos en tareas críticas	Media	Alto	Priorización MoSCoW, división de tareas y planificación conservadora
Uso excesivo de memoria	Baja	Alto	Pooling de objetos, limpieza de escenas inactivas, control de instancias

• Los riesgos son revisados en cada Sprint Review y actualizados en la wiki técnica.

• Godot Engine 4.2 Docs: https://docs.godotengine.org
• IEEE 830-1998 – Software Requirements Specification
• OpenGameArt.org – Recursos visuales y sonoros
• itch.io Assets – Assets compatibles con licencia CC-BY-SA

Este documento técnico se considera un recurso vivo, que será revisado y actualizado tras cada sprint.
Refleja el diseño, la implementación y las decisiones técnicas vigentes en el desarrollo del proyecto Feudalia.
Su mantenimiento está a cargo del equipo técnico y es validado en cada reunión de planificación y revisión.