revisionSprints.md - UCM-FDI-DISIA/proyectois1-algoritmos GitHub Wiki

Sprint review

A continuación, incluimos la siguiente información de la revisión de cada Sprint:

  • Objetivo: facilitar la retroalimentación de información y fomentar la colaboración.
  • Resultado: cómo hemos revisado el Product Backlog para definir los elementos del siguiente Sprint.
    • Posibles ajustes generales del Product Backlog (véase el Kanban del Product Backlog).
  • Distinguimos qué elementos del Product Backlog se han “Terminado” y cuales no (véase en Kanban del Product Backlog).
  • Distinguimos qué avances se hicieron durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas
  • Cada uno hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento conseguido.
  • Proyectamos objetivos de cara al siguiente Sprint basándonos en el desarrollo actual.
    • La información útil que tengamos de las ideas de proyección se trasladan al Sprint Planning.
  • Revisamos la cronología, capacidades potenciales y mercado para la próxima entrega prevista.

1. Sprint 1.

Retroalimentación: Hemos repasado el contenido de todos nuestros documentos de especificación, de cara a dejar claro todos los objetivos para iniciar el segundo Sprint. Damos por terminado el Documento de Especificación.

1.1: Avances y dificultades encontradas:

Sobre el inicio de un proyecto:

Avances:

  • Se consigue crear un proyecto en C#, el lenguaje elegido.
  • Se implementan plugins para ayudar al trabajo en equipo.
  • Se estudia la estructura y funcionamiento de nodos nativo de Godot.
  • Se estudia e implementan funciones básicas de movimiento y animaciones.

Problemas y soluciones:

  • El plugin para Git necesita configurarse localmente. → Se soluciona con una explicación grupal para evitar problemas futuros.
  • El ratón y controles usuales no son predeterminados. → Se descubre e implementa el añadido de botones y configuración de formas de input del usuario.
  • Los códigos se rompen con la ordenación de archivos. → Se intenta solucionar a futuro con una estructura incial adelantada, en el Sprint 2 finalmente ordenando todo de una forma final.
  • Git duplica carpetas y archivos al usar el plugin. → Aparentemente solucionado cambiando la estructura general del proyecto y uso moderado del plugin.

2. Sprint 2.

En este sprint nos hemos centrado principalmente en comenzar a desarrollar el producto. Antes de ello ha sido necesario refinar los objetivos añadiendo nuevas historias de usuario, describiendo nuestro producto mínimo viable, añadiendo nuestra interpretación de tarea terminada y refinando tanto nuestro documento de gestión de riesgos como el ReadMe del repositorio de GitHub. Una vez teníamos claro el plan de acción se ha implementado en Godot el cuadrante personal del jugador, con su mapa diseñado y animado con los recursos que más adelante se podrán recolectar.

2.1 Avances y dificultades encontradas

Sobre la creación del mapa:

Avances:

  • Descubrimos que hay un nodo especial para los mapas con grid.
  • Conseguimos añadir colisiones al mapa y editar una forma de pintado nativa para el mapa.
  • Conseguimos diseñar un cuadrante del mapa con distintas zonas a explorar.
  • Conseguimos distinguir zonas con bloqueos y cambios de altura.

Problemas y soluciones:

  • El mapa tiene incontables errores visuales. → Arreglado cambiando a unos sprites más modernos y creando más capas para apilar sprites y arreglar/mejorar visualmente el mapa.
  • Las colisiones no existen en el TileSet. → Solucionado creando a mano la colisión para cada tile usado y creando una capa de físicas para el TileSet.
  • Las colisiones son muy toscas. → Resuelto cambiando la colisión del jugador a un círculo para que no se enganche tanto, y afinando más a mano la fluidez entre colisiones.
  • El funcionamiento de las escaleras es complejo. → Resuelto tras distintos intentos cambiando las colisiones y usando trucos visuales para su mejor uso (Cambio de colisiones y uso de tiles distintos). Se explica a todo el equipo cómo ajustar manualmente las colisiones para que el personaje pueda subir las escaleras.
  • El proceso de diseñar un mapa es muy tedioso y afecta al main (no podemos hacer merge). → Resuelto con una mejor estimación en futuros Sprints y creación local de copias para los documentos delicados por más seguridad.

Sobre la recolección de recursos:

Avances:

  • Implementamos árboles, minas de piedra y minas de oro con colisiones.
  • Conseguimos integrar los elementos en la cuadrícula del mapa.
  • Diseñamos una interfaz para que el jugador vea cuántos recursos tiene.

Problemas y soluciones:

  • Errores de depuración no identificados y animación del árbol no funcional. → Resuelto. Descubrimos que la raíz de ambos problemas era que el nombre de la clase de ArbolAnimado no se correspondía con el nombre del fichero .tscn.
  • Vemos que es común que el ordenamiento YSort de los objetos se desconfigure al mover los nodos. → Resuelto. Hemos añadido pruebas unitarias para comprobar que este problema no ocurre.
  • No conseguimos que el personaje interactúe con las fuentes de recursos. → Sin resolver. Hemos encontrado tutoriales y formas alternativas de programar esta mecánica, pero queda pendiente para el próximo Sprint solucionarlo.

Sobre Godot:

Avances:

  • Todos conseguimos instalar el programa, importar el proyecto y ejecutarlo.

Problemas y soluciones.

  • Dificultades para comenzar a usar el programa. → Resuelto. Aprovechamos una reunión para poner en común todo lo que sabemos de Godot y cómo hemos desarrollado nuestra parte.
  • Dificultades para hacer merge. → Resuelto. Identificamos que el problema se da sólo si varias personas modifican una misma escena a la vez. Hablamos para que esto no ocurra organizándonos y ante la duda hacemos una copia local.

Retroalimentación

Cada uno explica los avances que ha hecho en Godot, qué ha terminado y responde preguntas.

Se responden preguntas de distintas índoles: qué es una escena, dónde están los menús, cómo se divide una imagen en fotogramas, cómo se añaden colisiones en el mapa, cómo funcionan los nodos de recursos...

2.2 Cambios en el Product Backlog a raíz de esta reunión

Todo esto se ha visto reflejado en un mayor refinamiento del Product Backlog. En particular:

  • Hemos ajustado las prioridades para que se ajusten al Producto Mínimo Viable.
  • Nos hemos ajustado al criterio MoSCoW para la prioridad de las tareas.
  • Comenzamos a usar de manera sistemática la fecha de inicio de tareas para identificar si alguna se ha estancado.

Conclusión: Como equipo, revisando el proyecto, vemos que hemos tenido muchas dificultades de desarrollo que no se abordaron correctamente. Así que, de cara al siguiente Sprint buscamos elegir mejor las tareas a desempeñar, cuántas personas van a enfocarse en cada tarea, mejorar la comunicación de equipo (véase el Sprint Retrospective) y estimar bien la magnitud de las tareas.

3. Sprint 3.

El objetivo principal de este sprint era implementar la construcción de casas para la generación de aldeanos, así como el sistema de compra de soldados. También quedó pendiente del anterior sprint refinar el sistema de recolección de recursos. En cuanto a documentación, al inicio del sprint elaboramos lo relacionado con la gestión de calidad, para asegurarnos de que todos desarrollamos con los mismos estándares en mente.

En este Sprint, conseguimos completar todas las tareas con la profundidad esperada. Además, la cronología del desarrollo de tareas se ha ajustado correctamente a nuestra planificación inicial.

3.1 Avances y dificultades encontradas

Sobre la construcción:

Avances:

  • Programamos un crecimiento lineal de la población, con limite máximo por casa.
  • Entendemos con mayor profundidad el funcionamiento de botones y paneles.
  • Conseguimos añadir un menú de construcción plegable que activa el modo construcción para poder comprar una casa.
  • Se muestra por pantalla una casa con transparencia que sigue al ratón y que se puede construir al hacer clic, restando los recursos correspondientes.

Problemas y soluciones:

  • Por problemas de comunicación no todo el equipo tenía en mente el mismo crecimiento automático de la población. → Resuelto. Con puesta en común de visiones en una reunión se aclararon las discordancias para que todos siguiéramos trabajando en un mismo sentido.
  • El crecimiento de la población entraba en bucle infinito. → Resuelto. Tomamos un enfoque distinto para esta implementación.
  • No se mostraba el modo construcción ni la compra de la casa. → Resuelto. Arreglado revisando las llamadas a funciones entre documentos, puesto que no se estaban ejecutando correctamente.
  • Si intentabas construir la casa encima del personaje todo el entorno vibraba porque colisionaban. → Resuelto. Si colocas la casa encima del personaje aparece roja.
  • Ciertas tiles no tienen la colisión necesaria para evitar la construcción de la casa. → Pendiente por solucionar en el siguiente sprint.

Sobre la recolección de recursos:

Avances:

  • Conseguimos crear una HitBox en el personaje que emite una señal al interactuar con el recurso.
  • Se implementó un sistema de estados de los recursos: activo, en recolección, y depleted, con animaciones diferenciadas para cada uno.
  • Se integró la lógica con el ResourceManager, de forma que al completar la animación de recolección se suman correctamente los recursos al inventario global.
  • Se estabilizó la secuencia de animaciones de recolección implementando un Timer que regula la duración y transición entre estados.
  • Se implementó un estándar de nomenclatura para archivos y variables del proyecto, reduciendo errores derivados de diferencias entre entornos locales.

Problemas y soluciones:

  • El personaje no activaba la recolección de recursos al atacarlos. → Resuelto. Se rediseñó por completo la lógica de detección entre el jugador y los recursos. Se identificó que crear una HurtBox para cada recurso era más costoso y complejo que crear una HitBox para el jugador. De esta forma la HitBox comprueba directamente con las colisiones de cada objeto en vez de una nueva área por recurso.
  • Las animaciones de recolección se ejecutaban de forma errática o con lag. → Resuelto. Se corrigió con un Timer que controla la sincronización entre las fases de animación.
  • Al hacer pull de la versión actualizada, algunos recursos perdieron sus colisiones y estados. → Resuelto. Se descubrió que GitHub Desktop no sincroniza cambios de nombres de archivos dentro de Godot; los nombres se corrigieron manualmente y se estableció un protocolo de estandarización.

Sobre la compra de soldados:

Avances:

  • Se consiguió que el menú de soldados permanezca oculto al inicio y solo se muestre al pulsar el botón del cuartel.
  • Se implementó el cambio de visibilidad de los iconos “+” y "-" en sincronía con el estado del menú (visible/oculto).
  • Se integró la lógica del ResourceManager con el SoldierManager para que el reclutamiento de soldados reste automáticamente los recursos correspondientes (comida, oro, madera, piedra según el tipo).
  • Se añadió una función que desactiva los botones de cada tipo de soldado (ButtonWarrior, ButtonArcher, ButtonLancer, ButtonMonk) cuando los recursos son insuficientes, y los reactiva cuando el jugador vuelve a tener los materiales necesarios.
  • Se implementó una actualización automática del estado de los botones al producirse un evento ResourceUpdated, garantizando que la interfaz siempre refleje el estado real del inventario.
  • Se revisaron las referencias a nodos y rutas absolutas, garantizando que los CanvasLayer y botones estén correctamente enlazados.
  • Se implementó un sistema de cambio modular de valores de cada soldado.

Problemas y soluciones:

  • El menú de soldados se mostraba desde el inicio y no respondía al botón. → Resuelto. Se detectó que el evento Pressed no estaba vinculado correctamente por error de nombres de archivos y código. Se reescribió el método de conexión en _Ready() y creó un manager del HUD de soldados. Se cuidaron las rutas de acceso y se comprobó con mensajes de depuración (GD.Print), logrando que el menú se muestre y oculte correctamente.
  • El contador de soldados no aumentaba a pesar del código correcto. → Resuelto. El problema era una referencia errónea en los botones de reclutación. Se reescribió completamente el código para hacer un sistema de reclutamiento modular que llamase a ResourceManager.
  • Errores de formato y valores en los precios al hacer Hover sobre cada botón de reclutamiento → Resuelto. Se editó el mensaje para actualizarse automáticamente según los precios de forma modular.

Sobre Godot y Github:

Avances:

  • Aprendemos a resolver los problemas de GitHub con la terminal.
  • Aprendemos a manejar los merge con cambios en el main de forma más correcta.

Problemas y soluciones.

  • Dificultades para hacer pull tras un push erróneo. → Resuelto. Pudo solucionarse haciendo push forzado desde la terminal y, aquellos con dificultades para hacer pull, descargando el proyecto entero de nuevo (fetch all, reset).
  • Problemas con la modularización de ciertas funciones. Encontramos que algunas funciones no son fácilmente modificables, lo que nos dificulta ajustar y equilibrar el juego. → En progreso. Definimos un estándar de código modular para evitar este tipo de problemas en el futuro. Este tema se abortó en profundidad en la RTF de este Sprint.
  • Errores y warnings de depuración no identificados. → Resuelto. Ajustamos referencias y quitamos código que no se estaba utilizando (por ejemplo, el ZIndex de los recursos, porque utilizamos YSort).

Otros avances y problemas:

En este Sprint nos dio tiempo a abordar tareas de prioridad baja que iban más allá de los objetivos principales del Sprint.

Avances:

  • Ampliamos el mapa a los cuatro cuadrantes del diseño del juego original.
  • Ajustamos el diseño gráfico del menú de recursos.
  • Iniciamos un proceso metódico y documentado de RTF rutinarias. Véase el apartado de "Control de calidad" de la Wiki.

Problemas:

  • Pensábamos que la ampliación del mapa a los cuatro cuadrantes iba a ser rápido y sencillo, simplemente copiando y pegando el primer cuadrante. Sin embargo, nos encontramos que todas las colisiones, los bordes, la decoración no cuadraban, además de que habría que rediseñar las montañas para que los niveles se vieran bien. → Resuelto. Al final hemos tenido que hacer a mano los otros 3 cuadrantes y hemos tardado mucho más tiempo del que teníamos estimado.
  • Encontramos que el menú de recursos no permite ajustar manualmente el tamaño de las imágenes. → Resuelto. Se separa el menú en varios contenedores y colocamos las imágenes por encima del menú para ajustarlas libremente.
  • Identificamos que nuestro código está escrito en más lenguajes de lo esperado. → En progreso: la mayoría de archivos .gd son eliminables (plugins que no usamos, pinceles, ficheros que se transcribieron a C#...). Otros archivos son propios de Godot y gestionan datos del proyecto, luego no podemos modificarlos. De cara al siguiente Sprint nos proponemos limpiar el código para que no haya ficheros innecesarios en GitHub.

Retroalimentación

Cada uno explica los avances que ha hecho en Godot, qué ha terminado, qué se puede refinar y responde preguntas. Observamos que el Incremento de este Sprint es mucho mayor que el del Sprint pasado.

Se responden preguntas de distintas índoles: qué archivos entendemos que están bien modularizados, cómo hacer pull y push por terminal, qué pruebas unitarias quedan por hacer, qué funciones están terminadas y cuáles tienen que someterse a un proceso de testing más extenso...

3.2 Cambios en el Product Backlog a raíz de esta reunión

Todo esto se ha visto reflejado en un mayor refinamiento del Product Backlog. En particular:

  • Hemos añadido historias de usuario más concretas para poder referirnos a ciertas dinámicas del juego.
  • Hemos priorizado aquellas implementaciones que nos acercasen a nuestro PMV.
  • Hemos identificado historias de usuario poco claras que queremos revisar de cara al siguiente Sprint.

Conclusión: Como se ha expresado en el Sprint Retrospective, el equipo está muy satisfecho con este sprint dado que la organización y priorización de tareas ha sido muy acertada. Nos hemos enfrentado a dificultades las cuales han sido comunicadas y resueltas conjuntamente. Con el resultado de este sprint (a falta del refinamiento de la construcción de la casa) ya estaría completamente implementada la dinámica del juego respectiva al propio territorio.

4. Sprint 4.

El objetivo principal de este sprint era implementar las funcionalidades multijugador (simultaneidad y ataque/batalla), exportarlo a web para poder jugar desde cualquier dispositivo y desarrollar el combate. Además, se dedicó tiempo considerable a pulir tareas pendientes de construcción y a la documentación interna para la gestión de calidad (RTF y Documento Técnico).

En este Sprint, conseguimos completar la mayoría de los incrementos principales y las tareas de gestión interna. Sin embargo, el esfuerzo de adaptar el código ya existente a la función multijugador fue un imprevisto más costoso de lo esperado, y la implementación del login, que se había planteado como tarea secundaria, no se completó en su totalidad.

4.1 Avances y dificultades encontradas

Sobre la función Multijugador y versión web:

Avances:

  • Se completó la investigación de las opciones multijugador, decantándose por Itch.io y el plugin GDSync de Godot para la red.
  • Se consiguió cambiar el código a otro lenguaje útil para web, además de conseguir subirlo todo a web para que se pueda jugar desde cualquier dispositivo.
  • Se ha conseguido que dos jugadores se conecten a la misma partida de forma simultánea.
  • Se construyó una estructura modular para futuras ampliaciones del modo online, evitando tener que reescribir el sistema más adelante.

Problemas y Soluciones:

  • Alto coste de transcripción: Para usar el plugin, fue necesario cambiar todo el código de C# a GDScript. → Resuelto: Esta transcripción fue muy costosa en tiempo y no supuso un avance material directo, llevando a costar la gran mayoría del trabajo del sprint de dos desarrolladores.
  • Problemas de exportación: No se puede exportar el codigo desde C# → Siguiendo el cambio de código, hubo que cambiar también la versión del motor de desarrollo, plantillas de exportación y formatos.
  • Errores de formato en la versión web: No se podía jugar online → Solucionado, se estudió la importación HTML del juego y descripción. Tras el fallo de este, se usó la herramienta nativa de la web para convertir en jugable el proyecto. Se tuvo que abandonar la idea de página HTML visualmente atractiva por falta de permisos en la página.
  • Problemas de transcripción: Al transcribir, se produjeron errores en funcionalidades que antes sí funcionaban. → Resuelto: el equipo hizo una verificación de funcionalidades post-traducción con objeto de encontrar y refactorizar las funcionalidades rotas, aislando la lógica central en módulos GDScript limpios, recuperando la estabilidad del código base.
  • Se encontraron pequeños lags en la sincronización de acciones complejas (movimiento de la cámara o del personaje principal) al haber dos jugadores. → En progreso. Esto se abordará con un refinamiento del protocolo de comunicación y una mejora de eficiencia del código en el próximo sprint.

Sobre la Batalla:

Avances:

  • Se diseñó el campo de batalla en una escena separada para mostrar el ejército de ambos jugadores. Esto ha sido especialmente útil para poder desarrollar en paralelo, en una escena completamente independiente del nodo main principal.
  • Se implementó una lógica de victoria/derrota basada en el cálculo de una media ponderada por jugador tomando el número de soldados y sus respectivos tipos, así como una pantalla win/lose mostrando el resultado final.
  • Se añadieron animaciones básicas de ataque de soldados en el centro del campo de batalla, a modo de feedback visual.
  • Se probó la escena con múltiples configuraciones de ejército para garantizar estabilidad.
  • Se generó una pantalla final capaz de mostrar los resultados de la batalla y la capacidad de cada uno de los ejércitos.
  • Se consiguió coordinar la implementación de la mecánica de batalla con el modo multijugador.

Problemas y Soluciones:

  • Dos miembros del equipo implementaron los timers de batalla con enfoques ligeramente diferentes (uno global, uno de instancia), lo que generó redundancia. → Resuelto: En lugar de eliminar la implementación global, se le dio una nueva utilidad para gestionar los estados del juego (recolección, ataque, resolución), asegurando que el trabajo no se perdiera.
  • El botón de batalla no se hacía visible al entrar el personaje en el área de piedra. Esto se debió a un error de herencias y tipos de nodos (Area2D vs Node2D). → Resuelto: Se normalizó la cadena de herencia de los nodos de control y se reconfiguró la señal del Area2D para activar un nodo de tipo CanvasLayer, que garantiza que el botón se muestre correctamente en el viewport.
  • El personaje podía atravesar el botón de batalla. → Resuelto: Se añadió al botón una colisión de modo que, aunque el botón no pudiera ser atravesado, tampoco bloqueara el paso y el área de detección (trigger de visibilidad) siguiera funcionando correctamente.
  • Inicialmente, el campo de batalla recibía un número aleatorio de soldados en lugar del número real (tanto para el jugador activo como para el enemigo) y el posicionamiento era incorrecto. → Resuelto: Se implementó una función de serialización que garantiza que el SoldierManager pase el recuento real de tropas antes de cargar la escena de batalla. El posicionamiento se corrigió utilizando spawn points predefinidos vinculados al ID del jugador.
  • Inicialmente, el número de tropas del enemigo era aleatorio, en vez de reflejar el ejército del otro jugador conectado (porque la batalla se implementó antes que el multijugador). → Resuelto: Se abordó el problema desde distintos enfoques, probando varias funciones de GDSync hasta dar con una que no diera problemas de sincronización. La resolución de este problema fue especialmente útil para entender mejor qué archivos eran comunes a ambos jugadores, cuáles no, qué papel tenía el host y para ver que las conexiones funcionan de manera asíncrona.

Sobre las tareas de pulido del Sprint pasado (Construcción de Casas):

Avances:

  • Se implementó exitosamente la restricción de construcción de casas: el jugador no puede construir en el agua.
  • El jugador no puede construir en rampas, escaleras, puentes, desniveles, ni encima de una fuente de recurso. El backlog de pulido de construcción ha sido completado al 100%.

Problemas y Soluciones:

  • Implementar la restricción de construcción sobre el agua fue complejo. El subsuelo base del mapa incluía agua, lo que impedía usar la lógica (por grupos) exitosa aplicada a los recursos. → Resuelto: Se intentó usar el ID del tile de agua sin éxito. Finalmente, se optó por eliminar el agua del suelo base y se añadió una restricción de construcción basada en los niveles del mapa, lo cual es más robusto y fiable que el tile ID para las zonas de agua.

Sobre Documentación y Gestión Interna:

Avances:

  • Se definió y documentó el proceso de evaluación de la RTF para los compañeros.
  • Se redactó un Documento Técnico inicial con el listado de herramientas y tecnologías clave del proyecto.
  • Se revisaron las colisiones de los 4 cuadrantes del mapa y se aplicó el estándar de modularidad a las nuevas funciones.
  • Se mejoró la claridad del repositorio GitHub.

Problemas y Soluciones:

  • La organización de las RTF con los compañeros presentó errores en la distribución de secciones y la comunicación fue tardía. → Pendiente: Aún no hemos recibido todos nuestros RTFs ni se han podido celebrar reuniones de feedback. Se debe reajustar el protocolo de comunicación y seguimiento de la RTF para el próximo ciclo.

Retroalimentación

Todo el equipo pone en común los avances realizados. En este Sprint la retroalimentación ha sido distinta a los anteriores porque todas las mecánicas nuevas implementadas son esencialmente distintas a nada que hubiéramos programado antes.

Se comenta cómo acceder a la versión web del juego, cómo ver los lobbys creados desde GDSync y cómo ajustar distintos parámetros que afectan al ciclo de juego. Por ejemplo, se explicó cómo cambiar los tiempos de una partida, lo cual es útil para realizar las pruebas unitarias.

Además, en un intento de demostración del funcionamiento del modo multijugador, descubrimos que la conexión entre jugadores funciona mejor entre distintos dispositivos que desde la misma máquina. Y no sólo eso, distintas versiones del proyecto en distintas máquinas también podían conectarse. De esta forma, durante la retroalimentación pudimos entender mejor cómo funciona GDSync: no puede funcionar sin conexión a internet porque los lobbys se crean en la red, no funciona bien desde un mismo dispositivo porque se inicializa GDSync en la misma máquina 2 veces (o no, porque el funcionamiento de esa parte del código es asíncrono), sí funciona bien desde varios dispositivos porque se inicia GDSync una única vez en cada uno...

En definitiva, esta retrospectiva fue una puesta en común tanto de incrementos y funcionalidades como de ideas y suposiciones sobre porqué funcionaba el modo multijugador en algunos escenarios y en otros no.

3.2 Cambios en el Product Backlog a raíz de esta reunión

Todo esto se ha visto reflejado en un mayor refinamiento del Product Backlog. En particular:

  • Hemos añadido historias de usuario para incluir sugerencias del profesor (posibilidad de "jugar contra la máquina").
  • Hemos cerrado las historias de usuario que nos llevan al PMV (a falta de refinar el multijugador).
  • Hemos modificado algunos documentos de la Wiki de nuestro proyecto, y en particular algunas historias de usuario, en base a las RTFs recibidas de otros equipos.

Conclusión: Como se ha mostrado en el Sprint Retrospective, el equipo está satisfecho por haber superado el gran obstáculo de la transcripción y por establecer un modo multijugador funcional y razonablemente estable. El Incremento funcional es grande, llegando a obtener un PMV a falta de pulir el modo multijugador para que funcione correctamente en casos límite (gestión de desconexiones, partidas paralelas en distintos lobbys, exportación a la versión web del modo multijugador...).

Sin embargo, a modo de autocrítica, se debe señalar la planificación optimista: el rendimiento se vio afectado severamente por la presión académica (exámenes), resultando en una distribución irregular de la fuerza de trabajo (4 personas la primera semana, 3 la segunda). Esto causó que las tareas secundarias, como el Login/BD, no se pudieran desempeñar. También quedó pendiente para el siguiente Sprint la configuración de un segundo cuadrante funcional para el otro jugador (añadir botones de ataque, edificio de reclutamiento, recursos...).

5. Sprint 5.

En este sprint hemos avanzado en cuatro líneas de desarrollo principalmente: implementar las mecánicas de recolección automática (con la construcción de edificios especializados), construir puentes para poder explorar nuevos territorios, perfilar el multijugador y añadir un bot automático. Antes de ello hemos añadido y ajustado nuestras historias de usuario para incluir las sugerencias del profesor y adaptarlas a nuestro producto actual. Una vez teníamos claro el plan de acción se realizó un trabajo de investigación bastante complejo en comparación a Sprints pasados para implmentar cada tarea. Además, hemos decidido que la tarea adicional de inicio de sesión no es imprescindible y hemos preferido dedicarle tiempo a otras funcionalidades.

De forma adicional, fuera de los objetivos que nos habíamos planteado, y aplicando la Ley de Parkinson, se ha adelantado parte del pulido del juego: se han añadido sonidos, transiciones entre escendas y se ha comenzado a utilizar un plugin para poder jugar a Feudalia en dispositivos móviles.

5.1 Avances y dificultades encontradas

Sobre la recolección automática:

Avances:

  • Se implementa la construcción de edificios especializados.
  • Se implementa la asignación de aldeanos a edificios de recolección especializados.
  • Se implementa un Navigation Map y un algoritmo A* para el movimiento de los aldeanos, a falta por pulir en el próximo Sprint.

Problemas y soluciones:

  • Los recolectores se chocan con las paredes y no bordean los objetos del mapa. Como solución se ha ajustado el NavigationMap para tener en cuenta las zonas no transitables.
  • En un principio, no interactuaban correctamente los edificios especializados y sus NPCs correspondientes con el personaje. Se solucionó moviendo la instancia de casas a la misma escena que el jugador, y así ya se detectaban las áreas de colisión.
  • Se encontraron dificultades en la aparición de NPCs, y en su movimiento hacia los recursos. Lo primero se arregló aplicando la misma lógica que la construcción de casas para detección de terreno válido. Para lo segundo, se necesitó crear un método que instanciara los recursos fuera del tilemap, para su reconocimiento por parte del algoritmo que controla el movimiento de los personajes, para que estos detectaran la ruta como alcanzable.

Sobre la construcción de puentes:

Avances:

  • Implementamos puentes rotos que pueden construirse por un coste material. Una vez construidos, el personaje puede cruzarlos para llgar a nuevas zonas del mapa.

Problemas y soluciones: *

Sobre el modo PVE (bot automático) y PVP (modo multijugador):

Avances:

  • Se consiguen implementar dos modos de juego independientes: un jugador contra la máquina / dos jugadores que se enfrentan en línea.
  • Implementamos un ejército aleatorio automático basado en tu ejército actual cuando juegas en PVE.
  • Se consigue desvincular el PVE de GDSync (al principio, en PVE el jugador estaba sólo en un lobby, por lo que también dependía del plugin).
  • Se gestiona que pueda haber múltiples partidas independientes (antes sólo podían jugar dos jugadores en el modo multijugador. Ahora, si hay otra pareja interesada, puede unirse a un lobby independiente y jugar).
  • Se gestionan caídas en el modo multijugador: si tu compañero sale de la partida, tu juego cambia automáticamente a modo PVE para que puedas terminar la partida con normalidad.
  • Se establece un sistema de fallback a PVE para gestionar cuando no se ha encontrado contrincante en un tiempo determinado.

Problemas y soluciones.

  • Dificultades para gestionar PVE-PVP. → Resuelto. En varias ocasiones varios desarrolladores se solaparon en esta tarea con distintas visiones de implementación. Tras comunicar todo esto, se restauró y ajustó una versión funcional del juego.
  • Dificultades para gestionar el ejército enemigo en modo PVE. → Resuelto. Identificamos que el problema se daba porque el PVE usaba un lobby para 2 jugadores en el que estaba sólo, así que hacía accesos a null cuando intentaba comprobar la información del adversario.
  • Cuando un jugador avandona una partida multijugador, queda un hueco libre en el lobby al que podía unirse un tercero, generando muchos bugs impredecibles. → Resuelto. Se gestiona que, en el cambio a PVE, el jugador activo también abandone el lobby.
  • Hay veces que, principalmente por problemas de conexión, un jugador le da al botón "PVP" y no consigue conectarse con otro jugador. → Resuelto. Se implementa un temporizador para que, si no puede empezar la partida multijugador en 30 segundos, empiece una en modo PVE.

Sobre el modo PVP (modo multijugador) y la versión web:

Avances:

  • Se identifica la causa del problema inicial y se soluciona: los ajustes de exportación a html no eran correctos.
  • Se identifica la causa del problema derivado. Queda pendiente explorar todas las vías para solucionarlo.

Problemas y soluciones.

  • No podíamos ver la consola del juego al ejecutar el programa en itch.io, así que no sabíamos qué estaba fallando. → Resuelto. Descubrimos que sí podemos ver la consola de depuración a través de las "Herramientas para desarrolladores" que se ecuentra en un menú desplegable de Chrome.
  • GDSync no se estaba iniciando en itch.io. → Resuelto. Un mensaje de error indicaba "Build configuration: no GDExtensions support", con lo que supimos que los plugins no se estaban exportando. Cambiamos varias cuestiones en los menús de configuración de exportación en Godot y solventamos el problema.
  • GDSync se iniciaba en itch.io, pero aún así no se conectaba. → Resuelto. Investigando en la documentación de GDSync encontramos que el plugin aún está en desarrollo y no se puede exportar a html5 de forma nativa. Sin embargo, en la propia documentación, ofrecen una IP que hace el papel de "servidor externo de prueba" con el que sí se puede exportar.
  • GDSync se conecta, pero itch.io no puede acceder a la IP que nos ofrecen los desarrolladores por un problema de contenido mixto: itch.io funciona en https (seguro) y no puede acceder al ws (no seguro) asociado a la IP. → En progreso. Revisando en foros de GitHub (GDSync es de código abierto, se puede consultar aquí) encontramos que nuestro problema coincide exactamente con un issue abierto desde hace 3 meses (issue #90) y que los desarrolladores están trabajando en ello.

En este Sprint no se pudieron hacer más avances en la exportación web del multijugador. Se han sopesado distintas formas de abordar el problema: utilizar un servidor externo alternativo a itch.io, cambiar las configuraciones de Chrome... Pero no está claro si es posible solventar este problema con las herramietas utlizadas.

En el Sprint siguiente se seguirán investigando posibles soluciones, y los resultados obtenidos se plasmarán en el Review. En caso de sea un problema irresoluble, se marcarán las tareas como completadas y se prescindirá del modo multijugador web. En este caso, los jugadores de Feudalia sólo podrían jugar PVP descargando el fichero ejecutable del juego.

Retroalimentación

Cada uno explica los avances que ha hecho, qué ha terminado, qué dificultades a encontrado, cómo ha intentado solucionarlas y responde preguntas.

Se ponen en común avances absolutos y avances que tienen que ser pulidos. Debatimos sobre cómo se pueden abordar algunos problemas complejos y qué tipo de cambios se puede hacer para conseguir que la recolección automática funcione y que el modo multijugador exportado en html5 funcione en versión web (como se expuso antes, hay dudas sobre si es posible).

5.2 Cambios en el Product Backlog a raíz de esta reunión

Todo esto se ha visto reflejado en un mayor refinamiento del Product Backlog. En particular:

  • Hemos ajustado las prioridades de algunas tareas. Por ejemplo, hemos decidido que no vamos a implementar un inicio de sesión, ya que no añade funcionalidades y no es una mejora sustacial en términos de calidad para nuestro producto.
  • Hemos seleccionado qué funcionalidades extra, fuera del PMV, queremos implmentar para el producto final.
  • Reordenamos las prioridades en base a las decisiones tomadas.

Conclusión: Como equipo, revisando el proyecto, vemos que hemos tenido muchas dificultades de desarrollo que se han solapado en distintos momentos, dificultando la depuración del proyecto. Así que, de cara al siguiente Sprint, buscamos ser más meticulosos con el testeo del juego y más comunicativos y específicos cuando encontramos un problema (ver Sprint Retrospective).

6. Sprint 6.

Sobre el modo PVP (modo multijugador) y la versión web:

Avances:

  • Se identifica que el problema es más complejo de lo esperado.

Problemas y soluciones:

  • Para acotar el problema, hemos utilizado un ordenador como servidor http con la esperanza de que así pudiéramos evitar el error por contenido mixto y asegurarnos de que la versión exportada pudiera ser funcional. → Camino sin salida. No funcionó, y el texto de error sugiere que el servidor debe configurarse para usar https.
  • Alterativas a itch.io (en ello).
  • Falta de opciones y otras alternativas plausibles. → Pedimos ayuda. Escribimos en el issue del repositorio GitHub de GDSync preguntando por alternativas, avances o soluciones, para ver si la comunidad había encontrado vías alternativas que no hubiéramos considerado.

Última actualización: 01/12/2025.