10. PRUEBAS Y GENERACIÓN DE CÓDIGO

10.1. PRUEBAS.

Debido a las características del desarrollo, con ciclos de implementación continuos, no se ha establecido un plan detallado de pruebas. En cada funcionalidad o mejora que se implementaba, se hacían las pruebas necesarias para comprobar su correcto funcionamiento.

Una vez implementadas un paquete de funcionalidades, se pasaba a hacer una prueba de integridad con el resto del nivel. Como los niveles son independientes entre sí, ya que están guardados en diferentes escenas de Unity, con estas pruebas son suficientes para garantizar que no se provocan problemas con el resto de clases y componentes del juego.

En la etapa final del desarrollo, sí que se han hecho muchas más pruebas generales basadas en comprobar la coherencia y la integridad de todos los elementos del juego.

Por desgracia, por falta de tiempo y previsión de contacto con gente que tenga el perfil objetivo del videojuego, no se han podido hacer las pruebas generales con usuarios. Igualmente, me he dado cuenta de que estaban mal planificadas ya que al estar al final de toda la planificación, no quedaba mucho margen para mejoras aunque se hubiesen podido realizar.

10.2. DESPLIEGUE WEB.

La forma de distribución del juego elegida ha sido una aplicación web. Como el propio Unity ya da la posibilidad de generar el contenido en este formato, se optó por usar su servicio en la nube con integración continua ^[16]. De esta forma se tiene un seguimiento de las generaciones de código que se van publicando de forma automática en un su plataforma web.

A la hora de implementar se han tenido que realizar ajustes en la posición de los componentes debido a la menor resolución nativa con la que se suele trabajar en el entorno web. Eso no ha impedido que el resultado sea muy similar al ofrecido en un formato de aplicación de escritorio convencional.

A pesar de haber distribuido el juego como un elemento web como se tenía planeado, este apartado del proyecto ha resultado ser menor del esperado. La planificación inicial contaba con algún tipo de soporte web alojado en un servicio de host que no ha podido realizarse. El resultado pues, aun tratándose de un aplicativo web, no se ha podido modificar para adaptarlo a un entorno más profesional de plataforma de videojuegos web.

10.3. PROBLEMAS CON LAS VERSIONES DE UNITY

A lo largo del proyecto han surgido dos problemas totalmente diferentes con la versión de Unity usada.

El primero de ellos surgió en una fase temprana del desarrollo cuando se intentó usar la funcionalidad de integración continuada en la nube explicada anteriormente. En su última versión estable, Unity ha cambiado la tecnología usada para la portabilidad a plataforma web. Ha pasado de usar la propia que tenía integrada históricamente por tecnología WebGL. Esto ha provocado que todavía no tenga integrado el despliegue automático en la nube. Para poder aprovechar las ventajas del Cloud Unity Build se optó por cambiar a una versión anterior que no provocase errores a la hora de compilar el código remotamente.

La otra problemática, cuyo efecto era más grave, vino dada en la última etapa de desarrollo. En las pruebas rutinarias del juego se experimentaba unas bajadas irregulares pero continuadas en la tasa de imágenes, lo cual provocaba unos molestos “tirones” a la hora de mover al personaje. En un principio creía que podría estar ocasionado por la carga gráfica del juego ya que, aunque los modelos usados son muy básicos, contienen muchos más triángulos de los que deberían debido a la herramienta con la que han sido usados.

Tras buscar investigar cual era un número razonable de triángulos para una escena de un juego, constaté que los modelos creados estaban igualmente muy por debajo del umbral de la carga poligonal de un modelo corriente.

Después de usar la herramienta de inspección de rendimiento de Unity, detecté que efectivamente la carga de cpu relativa al renderizado de la imagen era menor del 10%, un porcentaje muy aceptable. En cambio, se originaban picos irregulares asociados a la gestión de las físicas, los cuales cuadraban perfectamente con la problemática detectada. Tras buscar información sobre este tipo de problema, encontré que viene dado por un bug interno de Unity que poseen unas pocas versiones lanzadas. Nuevamente se cambió por una versión mayor, aunque inferior a la última para poder seguir usando el Cloud Unity Build, y se solucionó sin mayor altercado.

11. PLANIFICACIÓN FINAL.

11.1. PLANIFICACIÓN TEMPORAL.

En el siguiente diagrama se muestra la planificación temporal final del proyecto con los tiempos reales de desarrollo. En general ha habido un retraso generalizado a causa del aprendizaje Unity, el cual ha sido más laborioso de lo esperado. Una vez llegado al final de la planificación se ve las tareas de pruebas generales e integración con web han sufrido grandes recortes. Los requisitos funcionales han podido ser llevados a cabo con éxito dentro del margen establecido. La duración estimada del trabajo corresponde con unas 644 horas ya que se estima una media de 4 horas trabajas al día (aunque el fin de semana se hacían más que compensan las de algunos días laborales y unos días que estuve fuera en el mes de agosto).

11.2. PLANIFICACIÓN ECONÓMICA.

Teniendo en cuenta que no ha sido necesaria la adquisición de ningún tipo de hardware, que el software que se ha utilizado (principalmente Unity y MagicaVoxel) es gratuito y que los efectos de sonido son libres, los costes económicos del proyecto son esencialmente derivados de los recursos humanos. En este caso, existe un perfil de trabajador principal que es el programador, así como un perfil secundario, el diseñador, aunque en la práctica han sido la misma persona. Con tal de realizar una valoración económica hemos asignado un precio por hora trabajada a cada uno de estos perfiles:

•  Programador: 25€/h
• Diseñador: 30€/h

12. CONCLUSIONES.

Al finalizar este proyecto y repasar los objetivos iniciales puedo afirmar que la mayor parte de ellos se ha cumplido satisfactoriamente. De hecho, el resultado se asemeja en gran medida a la idea concebida en un principio. El desarrollo del videojuego ha generado un producto acabado y con cierta entidad propia.

En primer lugar, he logrado plantear un diseño que incorpora la posibilidad de modificación de código por parte del usuario, aportando un enfoque jugable distinto. Su implementación se ha llevado a cabo no sin complicaciones y limitaciones impuestas por el tiempo y conocimiento del motor de desarrollo. A pesar de ello, el resultado cumple con las expectativas propuestas.

En segundo lugar, se ha logrado captar la intención de mostrar los efectos de un código de programación de forma visual mediante las características propias de un videojuego. Por otro lado, la generación del código distribuible ha sido funcional como videojuego web pero con un alcance menor del planeado. Las opciones de exponer el resultado como un elemento web atrayente han sido supeditadas por motivos de prioridad marcados por la limitación temporal.

En todo caso, personalmente, ha sido muy enriquecedor aprender en un ámbito que me era desconocido y que me despertaba mucho interés. Además, puedo concluir que estoy satisfecho con el resultado obtenido y sorprendido gratamente con algunos aspectos como por ejemplo, la parte gráfica desarrollada y el aspecto visual obtenido.

Concluyo este proyecto con muy satisfecho y con ganas renovadas de enfocar mi vida laboral al mundo de los videojuegos.

13. MEJORAS DEL PROYECTO.

En mi opinión el proyecto podría ampliarse claramente en dos facetas diferenciadas:

• Ampliar el número de niveles y situaciones presentadas en el videojuego con nuevo “temario” añadido. Especialmente interesante me parece la posibilidad de expandir su universo con nuevos mundos diferenciados en los que la temática recurrente sea otra. Por ejemplo, se podría adaptar a las comunicaciones en red, poniendo a prueba el reconocimiento de puertos, redes y protocolos que darían pie a nuevas situaciones para resolver por parte del jugador pero con una mecánica no muy alejada de la presentada en este proyecto.
• Por otra parte, la otra ampliación clave sería el aspecto menos desarrollado al final de este trabajo: editar e incorporar funcionalidades a una plataforma web que incorpore el juego creado. Ampliando este campo se podría llegar a tener una aplicación web con diferentes videojuegos educativos, cada uno de ellos desarrollado de forma análoga a éste pero con peculiaridades específicas según el tipo de conocimiento que se quiera tratar.

Las pruebas y la generación de código son aspectos críticos en el desarrollo de software, incluyendo el desarrollo de videojuegos:

Pruebas:

1. Pruebas Unitarias:
   • Realiza pruebas unitarias para evaluar el funcionamiento individual de cada componente del código. Esto ayuda a identificar y corregir errores en una etapa temprana del desarrollo.
2. Pruebas de Integración:
   • Verifica la interoperabilidad de diferentes módulos o componentes al integrarlos. Asegúrate de que trabajen en conjunto como se espera.
3. Pruebas de Regresión:
   • Desarrolla y ejecuta pruebas de regresión para garantizar que las nuevas adiciones o cambios en el código no afecten negativamente a las funcionalidades existentes.
4. Pruebas de Aceptación del Usuario (UAT):
   • Realiza pruebas de aceptación del usuario para asegurarte de que el juego cumple con las expectativas del usuario final. Esto puede incluir pruebas beta con jugadores reales.
5. Pruebas de Rendimiento:
   • Evalúa el rendimiento del juego, incluyendo la velocidad de carga, la fluidez de las animaciones y la capacidad de respuesta, para garantizar una experiencia de juego sin problemas.
6. Pruebas de Seguridad:
   • Realiza pruebas de seguridad para identificar posibles vulnerabilidades y proteger el juego contra posibles amenazas, como hacks o ataques.
7. Automatización de Pruebas:
   • Utiliza herramientas de automatización de pruebas para ejecutar casos de prueba repetitivos de manera eficiente, especialmente en áreas propensas a cambios.
8. Pruebas de Estrés y Escalabilidad:
   • Evalúa cómo el juego se comporta bajo cargas de trabajo extremas y asegúrate de que sea escalable para soportar un gran número de jugadores simultáneos, si es relevante.
9. Pruebas de Usabilidad:
   • Realiza pruebas de usabilidad para evaluar la experiencia del usuario. Identifica posibles obstáculos en la interfaz de usuario y realiza ajustes para mejorar la accesibilidad y la experiencia general.

Generación de Código:

1. Estándares de Codificación:
   • Adhiérete a estándares de codificación establecidos. Esto garantiza coherencia en el código, facilita el mantenimiento y mejora la legibilidad.
2. Comentarios y Documentación:
   • Incluye comentarios en el código para explicar la lógica compleja y utiliza documentación clara para describir la arquitectura y el flujo del programa.
3. Desarrollo Basado en Pruebas (TDD):
   • Adopta la metodología de desarrollo basado en pruebas (TDD) donde escribes pruebas antes de escribir el código. Esto puede mejorar la calidad del código y facilitar la identificación temprana de problemas.
4. Revisión de Código:
   • Realiza revisiones de código periódicas con otros miembros del equipo. Las revisiones de código ayudan a identificar posibles mejoras, errores y aseguran la coherencia en todo el proyecto.
5. Refactorización:
   • Practica la refactorización de código cuando sea necesario. Mejora la estructura del código sin cambiar su funcionalidad para hacerlo más eficiente y mantenible.
6. Optimización de Rendimiento:
   • Optimiza el código para mejorar el rendimiento. Identifica y corrige cuellos de botella y utiliza prácticas eficientes de programación.
7. Control de Versiones:
   • Utiliza sistemas de control de versiones como Git para gestionar y realizar un seguimiento de los cambios en el código. Esto facilita la colaboración y permite revertir cambios si es necesario.
8. Principios de Diseño y Patrones:
   • Aplica principios de diseño sólidos y utiliza patrones de diseño cuando sea apropiado. Esto contribuye a la creación de un código más flexible y mantenible.
9. Pruebas de Código:
   • Implementa pruebas de código para verificar la calidad del código. Herramientas como linters pueden identificar errores de estilo y posibles problemas antes de la ejecución del programa.
10. Mantenimiento Continuo:
    • Realiza mantenimiento continuo del código para asegurarte de que esté actualizado, siga las mejores prácticas actuales y sea compatible con nuevas versiones de software y bibliotecas.