Memoria y documento de desarrollo

Pepooliet commented 5 years ago

Abro esta issue para notificaros de que estoy trabajando en la memoria y en el documento de diseño del videojuego.

Para ello me gustaría que los distintos miembros me entreguéis lo siguiente:

Herramientas empleadas: enumeración con descripción breve de las herramientas utilizadas para hacer vuestro trabajo. Programadores, diseñadora y tester.
Problemas encontrados: tanto programadores como tester comentadme los problemas que habéis ido encontrando, así como la solución aplicada.
Fuentes: sobretodo en el caso de la diseñadora, de donde se han sacado los sprites, los paquetes de texturas.. en resumen, todo. También la fuente de los sonidos ambientales.
Tareas: lista de tareas en las que habéis participado, así como la fecha de cumplimiento de las mismas. Esto es de vital importancia para hacer un seguimiento correcto del proyecto. Me gustaría que además de las que aparecen como issue, me comentéis las que NO aparezcan. Programadores, diseñadora y tester.

Pepooliet commented 5 years ago

En cuanto al documento de diseño, voy a emplear el que íbamos a presentar para el 21 de marzo con las modificaciones necesarias.

Pepooliet commented 5 years ago

He puesto la primera parte del documento de diseño, se encuentra en la wiki del repositorio, quiero puntualizar algunas cosas:

Las imágenes las iré añadiendo entre hoy y mañana, según se completen el arte de las interfaces.
He visto algunos ejemplos y me ha parecido apropiado hacer del documento de diseño cercano a un manual de instrucciones de un juego de los de antes, si veis que el tono es poco apropiado o demasiado poco profesional avisadme y lo cambiaré inmediatamente

Ahora mismo voy a poner los distintos personajes y a corregir el apartado de visión general del juego

ecoronado96 commented 5 years ago

¿El documento de diseño y la documentación del proyecto no tienen que ser un pdf en la raiz del proyecto?

Pepooliet commented 5 years ago

No he visto en ninguna parte que sea obligatorio, pero si es una buena práctica así será. De todas formas así podéis comentar cambios que querríais hacer.

Pepooliet commented 5 years ago

He creado la carpeta Documentación en la que guardaré ambas cosas, en formato pdf. El Documento de diseño está casi listo, le quedan algunas imágenes, me gustaría que me dieseis vuestra opinión respecto al tono y contenido.

ecoronado96 commented 5 years ago

He creado la carpeta Documentación en la que guardaré ambas cosas, en formato pdf. El Documento de diseño está casi listo, le quedan algunas imágenes, me gustaría que me dieseis vuestra opinión respecto al tono y contenido.

Te importa subir el .docx también? tengo que aportar lo correspondiente al desarrollo código, clases mas importantes, estados y el diagrama de clases.

Pepooliet commented 5 years ago

Eso irá en la memoria, subo el .docx de la memoria esta tarde.

Pepooliet commented 5 years ago

Ya está subido el documento de diseño.

Pepooliet commented 5 years ago

El documento de diseño está acabado. No me parece que le falte nada en comparación con otros. Dicho esto, propongo la siguiente estructuración de la memoria

Introducción
Equipo de trabajo
Ficha técnica
Objetivos del juego
Estados (distintas pantallas)
Mecánicas (incluye controles)
Análisis del código
Tecnología y herramientas de desarrollo
Problemas encontrados

Pepooliet commented 5 years ago

He subido la memoria del juego, faltan muchas cosas por añadir, pero los primeros 7 puntos están completos. Lo respectivo al código añadidlo en el punto 9, no tocaré nada. Comentadme que os parece.

ecoronado96 commented 5 years ago

Herramientas empleadas

Netbeans junto con la librería Slick2d para la programación del videojuego realizado.
Github para el control de versiones del proyecto, junto con su aplicación de escritorio Github Desktop.
Enterprise Architect para la realización del diagrama de clases de la documentación.
Adobe Xd como medio para definir las interfaces previa implementación de las mismas.
coolors.co esta web ha sido usada para definir una paleta de colores con concordancia para la interfaz, concretamente para la interfaz del estado Combate.
svgtopng.com para realizar transformaciones de formato en icono svg a imagenes png.
TileMap para realizar los mapas de sandbox y pruebas.

Problemas encontrados

Los problemas encontrados por mi parte como parte del equipo de programación han sido varios a lo largo del desarrollo del proyecto:

El primer problema encontrado, como era de esperar, la librería de Slick2d, ya que no la había usado previamente ni mi compañero del grupo de programación; ante esta situación decidimos implementar una pequeña demo sin una estructura por clases bien definida, para aprender como funcionaba slick y posteriormente realizar la estructura de clases que creímos más correcta al proyecto.
Durante el desarrollo de las pruebas tuve que realizar las tareas de investigación correspondientes a la carga del mapa, proveniente de TileMap y el uso de las capas que este ofrecía, tanto para la generación de los limites del mapa como de los personajes implicados. Gracias a los vídeos de CodingQuickTips pude realizar la tarea, a pesar de que sus vídeos facilitasen el aprendizaje las diferencias entre las versiones de TileMap, el cual a día de hoy se actualiza y la versión de Slick2d que lleva sin actualizarse unos años ha llevado a numerosos problemas de compatibilidad que acabe resolviendo editando los archivos .tsx de forma directa.
En los saltos de escenario entre mapas al principio fueron un problema ya que al haber implementado un juego por estados y Slick guardar el estado de estos tras acceder al salto entre estados y la posición del personaje, coincidente con las zonas de spawn de ambos estados, al haberse implementado como un mapa recurrente en el que por la misma entrada a un estado podemos volver al mapa anterior, como el personaje saltaba de forma directa sin moverse de la hitbox del spawn se detectaba un salto continuo entre escenarios de forma continuada e infinita, para resolverlo se estableció un reposicionamiento por desplazamiento respecto al spawn, es decir si el spawn se encontraba en la zona norte se reposiciona el personaje unas casillas mas hacia el sur del spawn para no causar la colisión y tener una transición entre escenarios correcta.
Uno de los problemas que mas dolores de cabeza me ha dado ha sido a la hora de realizar la IA de los enemigos, los cuales tienen un movimiento por actualización en una dirección, en el caso de no coger agro con el jugador, aleatoria; pero este movimiento esta ligado al valor de entero i de la función update() del bucle del juego que nos aporta Slick y dicha función no siempre es consistente, especialmente en cargas del juego entre estados aportándonos unos valores muy altos para i respecto al valor habitual que obtenemos y dándoles unas velocidades muy altas a ciertos enemigos para esos casos, la solución, aunque un poco tosca ha sido poner un límite a la velocidad que pueden adquirir estos enemigos.
Otro problema fue el guardado de la partida, ya que las clases de Slick no implementan serializable, tras hablar con el profesor, decidí agregar una clase con los valores mas importantes que debíamos guardar entre partidas.
Por ultimo y en referente al trabajo en equipo estuve esperando números archivos necesarios para implementar el juego, como los mapas, el cual pedí un mapa de prueba desde la primera reunión con el equipo, al no llegar ningún mapa hasta la penúltima semana antes de la entrega del proyecto, tome la decisión de aprender TileMap y realizar varios mapas que fueron usados para prácticamente la totalidad del desarrollo del proyecto, el cambio a los nuevos mapas de ultima hora supuso algunos problemas que han sido resueltos; de la misma manera el desarrollo de las interfaces de la totalidad del juego la hemos realizado desde el grupo de programación sin tener notificación o pautas del grupo de diseño; para ello recurrimos a Adobe Xd para facilitarnos el desarrollo de estas; considero que todo este trabajo nos ha llevado a invertir mucho tiempo en tareas que no eran programar el juego y ha tener mucha confianza en lo que hacíamos para que al cambiar los mapas y assets estos no provocasen errores graves.

Fuentes

http://slick.ninjacave.com/ tanto para el javadock de la librería como para los ejemplos, muy útilies en el desarrollo del juego.
www.youtube.com/user/MakiGAS93 para aprender a usar la libreria Slick2d
www.youtube.com/user/CodingQuickTips para aprender a usar e implementar TileMap en Slick y la aplicación por capas de elementos del escenario.
opengameart.org/content/tiled-terrains como el asset del mapa sandbox
www.flaticon.com para el icono de Github de la web que sirve de enlace al repositorio.

Tareas

Por orden las tareas realizadas durante el proyecto por mi parte son las siguientes:

Configuración del entorno de trabajo, Github y proyecto con librerías.
Investigación y construcción de un mapa con TileMap para las pruebas de desarrollo como Sandbox.
Carga del mapa por capas de forma independiente del mapa.
Estructuración por clases del proyecto de prueba Demo.
IA de movimiento y ataque de los enemigos.
Construcción de un segundo mapa de pruebas que simula una mazmorra y salto de escenarios respecto a las reglas preestablecidas.
Diseño y desarrollo de la interfaz y estado de combate con los distintos enemigos, la IA de estos en esta situación.
Menú principal del juego
Guardado de partida.
Resolver problemas al importar los nuevos mapas en el proyecto.
Estado Mazmorra y ciclo del juego 'Casa->Mazmorra->(si victoria)nuevo día'.
Animación del personaje Gato.
Página web del juego.
Documentación referente a la parte de desarrollo.

Javier-DlaP commented 5 years ago

Herramientas empleadas

Netbeans junto con la librería Slick2d para la programación del videojuego realizado.
Github para el control de versiones del proyecto, junto con su aplicación de escritorio Github Desktop.
Adobe Xd como medio para definir las interfaces previa implementación de las mismas.
Paint 3D para arreglar los fallos de los sprites que me daba la diseñadora gráfica y para crear imagenes que suplieran la falta de sprites durante gran parte del proyecto.

Problemas encontrados

Para empezar un gran problema fue aprender a utilizar la librería Slick2D ya que da muchos problemas al encontrar la documentación y ejemplo al ser una librería tan antigua y sin actualizaciones que no detecta Windows 10 y hemos tenido que suplir y solventar diversos problemas que esto provocaba, como fijar la resolución a 720p o tener que fijar el escalado de Windows al 100% ya que si se usaba otro escalado se producían bugs visuales.
Tras comenzar a implementar las animaciones me encontré con problemas al usar los frames de andar y del estado de reposo ya que todo se encontraba en la misma variable Animation y al ajustar los sprites a la animación, para solucionarlo creé 4 variables Animation, una para cada eje en la que diferenciaba los frames de reposo y movimiento.
Investigando el uso del ratón en slick me encontré con diversos problemas el mayor de ellos fue el de calcular las distancias entre donde hacer click y el personaje que controlas, la solución fue leer el javadoc correspondiente a este tipo de entrada y crear la función de calculo de la distancia ya que encontraba ejemplos en Internet.
Unos de los mayores problemas al inicio del proyecto fue la detección de colisiones con los muros del mapa, el detectarlo no fue muy difícil, lo complicado fue conseguir que al colisionar, no se saliera del mapa el personaje y que al chocarte pudieras deslizarte con la pared, para ello a colisionar con un muro el personaje vuelve a su posición anterior a colisionar con el muro y probar cada una de las teclas pulsadas para así no moverse en la dirección que causaba la colisión.
Intenté poner una imagen del mouse encima del predeterminado del windows pero al no encontrar y no recibir imágenes para testeo por parte de la diseñadora gráfica tuve que hacerlo por medio de un sprite que siguiera al mouse pero tenía mucho retardo y esto se canceló.
Al modularizar Enrique todo lo trabajado hasta el momento me costó un tiempo volver a situarme y entender como funcionaba lo previamente programado, la solución no fue más que leer poco a poco todo lo que había hecho.
Tras recibir los modelos de los personajes tuve que estar 2 semanas esperando a que ajustasen el personaje principal, pero ante la previsión de que no lo iban a arreglar correctamente ya que cuando se "arregló" no era como se pedía así que me tocó arreglar todos los personajes que me dieron ya que no realizaban lo que les pedía.
Creación de una interfaz de diálogos (creada por mi ya que no recibía ideas y seguía esperando sprites) que funcionaba y se ajustaba a cualquier resolución, lo cual no sirvió ya que no se definió correctamente la escala del juego y más adelante la tuve que crear de nuevo, por lo que me tocó diseñar e implementar esta.
Otro de los grandes problemas del proyecto fue la implementación de la acción de plantar las plantas, ya que al plantar, las plantas se tienen que renderizar en una posición diferente cada vez que Ruby se mueve, la solución pasó por la creación de un objeto huerto que contenía las hitbox de las posiciones del huerto y las plantas allí plantas, todo ello guardado en el mapa en forma de una matriz que contenía en cada posición la hitbox y la planta.
Como seguía esperando sprites por parte del diseño gráfico me tocó diseñar, e implementar las interfaces del inventario, el diálogo, el comercio y la elección de semillas al plantar, pero claro, para ello me tocó aprender a utilizar Adobe Xd.
Además también me tocó aprender a usar Paint 3D ya que permite trabajar con png y porque me tocaba arreglar todas las imágenes y crear png (creados por mi) que definían los objetos aún sin imagen y las plantas del huerto que aún seguía esperando.
Implementación de todos los objetos, el inventario de Ruby y el uso de estos en el inventario (ya que es dinámica su interfaz en el juego) y que todo tenía que seguir funcionado correctamente.
Para la implementación del huerto hubo bastantes problemas ya que al cambiar de escenarios se perdería el tiempo que llevaban las plantas creciendo, así que implementaron como hilos.
Creación de un objeto huerto que implementaba las mecánicas de planta y recogida con el interfaz gráfica además de su posición respecto de la hitbox del huerto en la que se encontraba.
Guardado en cada uno de los personajes los diálogos que ellos usarían y método para usarlos a partir de los funciones ya creadas para la interfaz de diálogo, para ello se creó un array con las frases para cada persona, quién hablaba en cada momento y si la conversación continuaba.
Cambio del objeto Npc a Gato y Abuela para diferenciar a ambos npcs ya que el cambio de esto afectaba a la mayor parte del programa, para ello tuve que cambiar todas las funciones referentes a npcs en el mapa y en las funciones de detección de click en npc.
Por último, lo más complicado y de lo que más tiempo me llevó fue la cuenta y uso de los diálogos y del estado del juego en el que se encontraba, además de tener en cuanta que del estado de hablar pasa al estado de comerciar, también espera a que el gato huya y que en caso del boss se activa colisionando con él, para esto creé booleanos, un entero para el control del estado en el que se encontraba el tutorial, frases clave para el paso de entre el dialogo y otras acciones y controladores que indicaban que frase tenía que decir cada personaje en cada momento.

Fuentes

Ejemplos de Slick de programas
Javadoc de la librería

Tareas

Diseño Gráfico:
1. Creación de sprites para suplir la falta de sprites durante el desarrollo del proyecto, tanto de objetos como que la animación de las plantas al crecer.
2. Aprendizaje de Paint 3D para arreglar los sprites que subían ya que seguía esperando más sprites del proyecto.
3. Aprendizaje de Adobe Xd para el diseño de las interfaces del videojuego (todas menos las del combate).
Testing:
1. Pruebas desde del inicio del proyecto hasta el final del proyecto ya que hasta varios días antes del proyecto no hubo testeo.
2. Solucionar los problemas provocados por lo que había programado.
3. Intentar dar soluciones a los problemas producidos por lo programado por Enrique.
Programación:
1. Investigación del método de implementación (e implementación) de animaciones, colisiones con muros e interacciones por teclado en Slick 2D
2. Detección del mouse dependiendo de la distancia a la que se encontraba el jugador de lo clickando.
3. Ajuste de todos los sprites en el programa.
4. Implementación del sistema de diálogos.
5. Implementación del sistema de plantar/recoger.
6. Implementación del sistema de comercio.
7. Creación de las interfaces necesarias para el uso de estas por teclado/mouse.
8. Creación del inventario y de todos los objetos del juego.
9. Sistema de diálogos que diferenciaran a los personajes y sus distintos diálogos.
10. Finalización del juego ordenando los diálogos del juego y creándolos ya que los proporcionados eran muy ambiciosos y abarcaban lo que teníamos programado.
11. Implementación de herramientas que permiten pasar del estado de hablar al comercio, al combate o a ver como huye el gato.
Diseñador web:
1. Aprendizaje del lenguaje Markdown, el cual no utilicé que me encontraba programando el final del juego y Enrique hizo esa tarea por mí.

Pepooliet commented 5 years ago

He acabado en principio los 10 primeros puntos de la memoria.

Enrique, me gustaría que vieses los apartados que pasaste mediante el .docx a parte, ya que he corregido un poco la sintaxis y he aplicado formatos especiales de letra para las clases, los objetos, las funciones y el vector movimiento, para que sean mas visibles en el texto y facilitar la comprensión.

Javier, en los problemas encontrados no he encontrado la solución aplicada a ninguno de ellos, he dejado justo al final del documento unos problemas que escribiste, con letra diferente, por si quieres añadirles la solución que aplicaste.

En el punto 11 me faltan por agregar unos problemas más, pero he tenido que seleccionar los que considero más relevantes.

He descartado de la memoria el diagrama de clases y el cronograma.

ecoronado96 commented 5 years ago

Voy a redactar esto según me encuentre los errores o elementos que vea que hay que modificar, modificaría el documento pero por lo que comentas lo debes de estar editando y no quiero que cause problemas.

En cuanto a los controles el movimiento además de por WASD es por las flechas del teclado y el inventario es la letra E no la I.
La exploración de la mazmorra que detallas de esta forma:

Exploración de la mazmorra: la mazmorra se compone de una serie de pisos repletos de enemigos, a los que podemos combatir o evitar, el final de la mazmorra es el final del juego

No es una descripción correcta, las mazmorras son seleccionadas de forma aleatoria y comprendidadas por un único nivel o piso de mazmorra, una vez vencido el boss Ruby recupera a su gato se cambia de día y sube de nivel y la dificultad de la mazmorra se incrementa y el ciclo se repite, esto ocurre hasta 3 veces, ya que el nivel máximo establecido para Ruby es 3.

Respecto a las tecnologías, herramientas y fuentes ulizadas
- Como teclogias y herramientas faltaría el lengua utilizado que seria Java, Adobe Xd es diseño de interfaces a secas añadir definición ahi es redundante, en todo caso seria diseño de interfaces y UX (user experience), y el TiledMapEditor ha sido usado tanto para los mapas de pruebas(sandbox) como para los mapas del juego final.
- En fuentes falta aplicar el enlace de los asset del mapa sandobox.
En problemas encontrados entiendo que es lo que estas llevando a acabo y falta que @Javier-DlaP exponga sus soluciones aplicadas y que @KinGJV y @MarinaFer expongan los suyos si es que han tenido alguno. He visto que no has colocado en este apartado los problemas encontrados referentes al equipo, en parte lo entiendo, pero teniendo en cuenta que el profesor durante las clases ha dado cierta importancia a la dificultad de las relaciones en los equipos de trabajo de un proyecto de videojuegos y con la experiencia que he tenido me gustaría que como mínimo se hablase de ello en un apartado conclusiones.
Falta el diagrama de clases, es un elemento fundamental en la entrega de una memoria de un proyecto que incluya algo de programación especialmente en Java, este diagrama es el que expone la estructura de clases y sus relaciones, y es el único medio del cual podemos disponer para mostrar esto de una forma sencilla sin necesidad de leerse todo el código; además también suele servir para hacerse una idea de la modularidad de un proyecto y su complejidad y magnitud. Existen muchos tipos de diagramas en ingeniera de software, pero desde luego el diagrama de clases es imprescindible en la documentación de cualquier proyecto.

Dándole otra vuelta al documento he visto que el índice del proyecto no esta referenciado, entiendo que estas dejando esto para el final, pero si tienes algún problema al hacer esto avísame. También he visto los roles desempeñados por el del equipo de trabajo nuevamente y he de aclarar algo Javier y yo hemos acabando programado por igual el proyecto, por lo tanto creo combeniente que los dos estemos como programadores por igual, además en mi caso además de programación, tal y como te expuse en las tareas, he acabado haciendo la web para que Javi pudiese acabar de incluir los diálogos y el ciclo del juego en relación a estos y no solo eso sino que también he realizado las tareas de diseño grafico y de diseño de nivel referentes a la creación de los mapas de pruebas (sandbox) y al diseño de interfaces tanto del menú como de combate y de igual forma me costa que Javi ha realizado las tareas de diseño gráfico referentes al diseño de interfaces (dialogos, comercio, inventario y menu_plantar).

Javier-DlaP commented 5 years ago

Ya puse los soluciones a todos los problemas encontrados

Pepooliet commented 5 years ago

Corregiré la el documento y memoria del juego aplicando lo que me habéis dicho. Por supuesto, entre los puntos que tengo que añadir se encuentran los de testeo, diseño gráfico y trabajo en equipo. Este último punto, como bien dices, es esencial, y trataré de reflejar de manera profesional los distintos problemas que han surgido. En cuanto al diagrama de clases, adjuntaré las capturas que me has pasado tal y como me las enviaste.

KinGJV commented 5 years ago

Herramientas empleadas

• Netbeans: para las pruebas de testeo pertinentes. • Github: para llevar un claro control de versiones. • TiledMap editor: para realizar los mapas finales y las correcciones a los mapas existentes. • https://www.imageenlarger.com/es.html : para redimensionar las texturas y crear nuevos mapas. • https://donjon.bin.sh/5e/dungeon/ : para la creación de layouts aleatorios que luego implementaría en TiledMap

Problemas encontrados

En la parte de testing el principal problema encontrado fue que el mapa principal (la granja) poseía un nivel de frames bajísimos que hacía imposible el jugar. Encontré la solución de la siguiente forma. Primero redimensioné el mapa a una escala mayor ya que quedaba mal estéticamente la proporción que elegimos. Después procedí a eliminar capas de decoración y a unificarlo todo en una misma capa para reducir la carga y así aumentar considerablemente los FPS. Por último, adapté el resto de las capas que poseían una función para así que el mapa cumpliera las mecánicas que estaban en el anterior mapa. El resto de las pruebas relacionadas con el testing fueron solucionadas casi inmediatamente por los programadores haciendo mi labor en ese aspecto casi innecesaria.

Tareas

• Testeo de las fases del juego. • Testeo de los mapas del juego. • Creación y adaptación de los mapas con las especificaciones del equipo de trabajo. • Ajuste de imágenes para correcta realización de mapas.

Pepooliet commented 5 years ago

He terminado la memoria. He incluido los puntos que faltaban en problemas encontrados y en herramientas utilizadas, el índice referenciado y el diagrama UML.

TecnologiaVideojuegos / proyecto-videojuego-team-ruby